[tex-k] [tex-live] make = gmake?
Karl Berry
karl at freefriends.org
Fri Aug 11 01:45:37 CEST 2006
Belated replies, sorry ...
TeXlive already needs gmake because of freetype2, i.e. XeTeX:
Ok, but it still seems philosophically desirable to me to allow use of
non-gmake. Not everyone builds within TL. You already said that the
parallel thing isn't critical right now, so is there any problem with
sticking to standard make? Are other gmake features useful to you?
I almost forgot: pdfTeX does need gmake allready. We got a bug report
from an OpenBSD user (who used stock bsd make) to that effect.
Separate from the freetype2 failure?
> Wouldn't it be possible to have a GNUMakefile and a Makefile in
Can autoconf do this?
Autoconf can certainly create Anything from Anything.in, but of course
that's not enough. (BTW, it would be "GNUmakefile" not "GNUMakefile",
last I knew, to be automatically found by gmake.)
And if it can maintain two versions of Makefiles, can it also
generate the right version (i.e. either gmake or make)?
AFAIK, there is nothing in Autoconf which "knows" about gmake vs. make
or will generate two different make flavors, etc. Basically all it does
is take the input file and substitutes a whole lot of variables.
If pdftex will require gmake, then I suppose the cleanest approach would
be to complain at configure time, like freetype2 does.
Meanwhile:
te>I think that the problem is that pdftex builds outside the source tree
Via VPATH?
(the build.sh script works this way). Not all versions of make support
this properly.
I do not see build.sh. Doesn't configure && make work? I hope no
add-on shell script is really needed. That would be an additional and
substantial complication.
Is that reason enough to switch to GNU make entirely?
It is true that only GNU make reliably supports VPATH.
karl
More information about the tex-k
mailing list