Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
> but I guess I don't understand your thinking here
a changed timestamp does not imply a changed file
add sh/bash to pain list
Posted Feb 22, 2007 6:05 UTC (Thu) by ajross (subscriber, #4563)
Just stop, basically. If you have an idea for (yet) a(nother) better make tool, then write it and stop with the uber-k00l one-liners, they don't make you look as smart as I suspect you think they do.
Posted Feb 22, 2007 7:07 UTC (Thu) by cate (subscriber, #1359)
make is also not so good (with a simple syntax) to handle double output files and semi circular dependencies (i.e. one makefile line to compile and generate the dependencies (.d files) for next make run)
The use of "touch" in a makefile show also design flaw to makefile syntax
I'll happy only after extentions of makefile (or a new make like tools) that could compile efficently (with short and simple syntax) also TeX and LaTeX files.
Posted Feb 22, 2007 12:50 UTC (Thu) by nix (subscriber, #2304)
What does make things nastier is the need for -stamp files everywhere to model X-to-many dependencies and cope with parallel make...
Posted Feb 22, 2007 12:52 UTC (Thu) by nix (subscriber, #2304)
$(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).
Posted Feb 22, 2007 13:24 UTC (Thu) by cate (subscriber, #1359)
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.
Posted Feb 22, 2007 16:52 UTC (Thu) by khim (subscriber, #9252)
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.
Posted Feb 23, 2007 22:16 UTC (Fri) by nix (subscriber, #2304)
*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
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
Posted Feb 24, 2007 10:25 UTC (Sat) by k8to (subscriber, #15413)
Posted Feb 22, 2007 18:52 UTC (Thu) by b7j0c (subscriber, #27559)
you asked what the weakness was, i told you. this does in fact impact users of very large build projects.
Posted Feb 23, 2007 23:33 UTC (Fri) by JohnNilsson (guest, #41242)
A computable file is a function from a specified set of files to a bytestream.
When a computable file is read the stream is computed and cached.
If the specified 'input'-files changes, inotify triggers a deletion of the cache.
A 'buildsystem' is thus only a set of computable files.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds