GNU bug report logs -
#75655
configure doesn't update Makefile
Previous Next
Full log
View this message in rfc822 format
> Date: Thu, 23 Jan 2025 20:54:59 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: schwab <at> linux-m68k.org, 75655 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>
> >> For this problem, the behavior is even worse for out-of-tree builds: the
> >> problem occurs the same way, but one of the suggested fixes from
> >> INSTALL.REPO leaves you without a Makefile, and the other one won't work
> >> but will probably delete valuable data.
> >
> > I don't see how this is relevant. "git clean" should be run in the
> > source tree (the build tree is not a Git checkout), and the other
> > fixes are for very specific problems.
>
> I think it is relevant: The fixes in INSTALL.REPO will not work in the
> out-of-tree case, no matter where you run them.
If INSTALL.REPO doesn't take out-of-tree builds into account, then the
instructions should be fixed or expanded to cover that case. But it's
a separate issue. This thread started by your describing build
problems, not problems with advice in INSTALL.REPO. If there are
build problems, they should be fixed first, because INSTALL.REPO is
just an advisory; if someone succeed in building Emacs from Git
without reading that file, it's still a win.
IOW, let's please separate the issues that need to be handled
independently, otherwise this discussion will diverge even more than
it has already, and we will be unable to fix whatever the problems we
have.
> You suggested "out-of-tree" builds to me, and it sounded like you
> thought they'd help fix or avoid this issue. They don't.
The suggestion was for the case where you need to produce several
builds from the same sources, which will help you to avoid the need of
removing artifacts of building for a different configuration, since
each configuration has its artifacts in a different directory. In
particular, such an arrangement should greatly reduce the need for
"make bootstrap".
When you say "they don't", does that mean you tried my suggestion and
it failed to do what you need, i.e. avoid having irrelevant artifacts
in the build tree, or does it only mean you found that INSTALL.REPO
doesn't cover that case well enough?
> >> Sorry I can't address the general git comments/"out of tree" builds in
> >> detail right now. I find git hard enough to use without committing
> >> changes so I don't actually push them (that one's confusing), and
> >> certainly won't use multiple clones. "Out of tree" builds are useless
> >> *to me* as long as they create thousands of files in the "source" tree;
> >> in this case, they make the problem worse.
> >
> > Fair enough, but you are proposing changes to Emacs's build machinery,
> > so this is not just about you and your personal workflows, right?
>
> Absolutely. I seriously do think that several other people will run
> into this issue when scratch/elisp-benchmarks is (rebuilt and) merged.
Maybe. But you described quite unique workflows, so I have my doubts.
> OOT builds are unrelated. Unless I can chmod a-w my emacs source
> directory and build from it, they're not "out of tree", and they're not
> for me.
I think you are mistaken. But then you haven't shown any details of
why these builds are not for you, so maybe I'm missing something and
you are right.
This bug report was last modified 141 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.