add sh/bash to pain list [LWN.net]

add sh/bash to pain list

Posted Feb 22, 2007 12:50 UTC (Thu) by nix (subscriber, #2304) [Link]

Looking at the most monstrous makefiles I could find (glibc and gcc) the occasional `move-if-change' is not a killer.

What does make things nastier is the need for -stamp files everywhere to model X-to-many dependencies and cope with parallel make...

add sh/bash to pain list

Posted Feb 22, 2007 12:52 UTC (Thu) by nix (subscriber, #2304) [Link]

I hate to say it, but

$(DVIOBJS): %.dvi : %.tex
echo 'Rerun to get' > $@.tmp; \
while grep 'Rerun to get' $@.tmp >/dev/null; do latex $< | tee $@.tmp; done; rm -f $@.tmp

simply is *not* killingly annoying nor difficult and certainly doesn't require any extensions to make(1).

add sh/bash to pain list

Posted Feb 22, 2007 13:24 UTC (Thu) by cate (subscriber, #1359) [Link]

It is an hack (echo, while, grep, tee, rm). Lucky there is only one implementation of TeX engine, with a fixed string.
And very annoying for bigger project, which includes more dvi files (plus ev. the pdflatex) and a lot of includes.
And to complicate: usually user will use bibtex, or some filter for indexes.

make is very good for tree dependencies (and timestamp), but it is not suited (and designated) for general build use.

Maybe because of Makefile programmer, but in a lot of programs you see: "run make clean before to compile the program" (when you change configuration, you patches programs, or now often, before/after a new ./configure). Is this not contrary to the spirit of make? Also kernel had such problems, showing that it is not easy to tell make the right dependencies.

I know that a lot of such problems are due to bad makefile programers, but this show that makefile is not more well suited for today build process.

add sh/bash to pain list

Posted Feb 22, 2007 16:52 UTC (Thu) by khim (subscriber, #9252) [Link]

Is this not contrary to the spirit of make? Also kernel had such problems, showing that it is not easy to tell make the right dependencies.

It's not easy to tell the right dependencies period. make has nothing to do with this: you can create perfectly manageable make-based system (see kernel 2.6) or you can create mess with any other system. Things like mod_ssl hack (one file has the C program, perl script to regenerale this program and data for said perl script - you should run perl+gcc or just gcc dependyng on type of changes) can not be sanely handled by ANY build system.

add sh/bash to pain list

Posted Feb 23, 2007 22:16 UTC (Fri) by nix (subscriber, #2304) [Link]

Quite so.

*Any* large system will soon acquire strange code generators and autobuild
rules involving them, and you'll *have* to have some way of telling the
code generator what the build rules are.

It can get insanely elaborate, e.g. gcc's horde of build tools using files
which might in extremis need to be built once with the build compiler,
once with the host compiler, *and* once with the target compiler
(libiberty is like this in Canadian cross builds); GCC's
build-a-makefile-on-the-fly system for building libgcc; or libjava's
`accumulate filenames and write most of the makefile on the fly' system
(all of which have good reasons to exist and are big improvements on what
predated them).

glibc is another good example, with automatic tree walkers finding the
`most system-specific suitable file, if any'...

The question of whether you put that stuff in CMake libraries or in files
included by the Makefile is somewhat academic, really. It still needs to
be there.

add sh/bash to pain list

Posted Feb 24, 2007 10:25 UTC (Sat) by k8to (subscriber, #15413) [Link]

Agreed hairy tricky tools are often enough needed. Agreed where they live for the sake of where they live doesn't matter. It's a question worth exploring if you can make viewing and editing the expression of that more sane one way or the other, I think.