| |||||||||||||
add sh/bash to pain listadd sh/bash to pain listPosted Feb 22, 2007 5:45 UTC (Thu) by b7j0c (subscriber, #27559)In reply to: add sh/bash to pain list by ajross Parent article: The Road to KDE 4: CMake, a New Build System for KDE (KDE.News)
> but I guess I don't understand your thinking here
a changed timestamp does not imply a changed file
(Log in to post comments)
add sh/bash to pain list Posted Feb 22, 2007 6:05 UTC (Thu) by ajross (subscriber, #4563) [Link] Indeed, you've discovered quite a conundrum there. For extra credit, please detail a solution that doesn't involve, say, computing an MD5 hash on every dependency of every target for every invocation. Or integrating your build tool into a source control system. Or the filesystem.
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.
add sh/bash to pain list Posted Feb 22, 2007 7:07 UTC (Thu) by cate (subscriber, #1359) [Link] Some makefiles build some files in an other directory, compare the files and eventualy they copy in the right location. It is an hack. It should be included in the makefile syntax.
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.
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
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
It can get insanely elaborate, e.g. gcc's horde of build tools using files
glibc is another good example, with automatic tree walkers finding the
The question of whether you put that stuff in CMake libraries or in files
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.
add sh/bash to pain list Posted Feb 22, 2007 18:52 UTC (Thu) by b7j0c (subscriber, #27559) [Link] what is with the chain jerking? your response has nothing intelligent to offer other than a thinly-veiled insult predicated on nothing at all.
you asked what the weakness was, i told you. this does in fact impact users of very large build projects.
add sh/bash to pain list Posted Feb 23, 2007 23:33 UTC (Fri) by JohnNilsson (guest, #41242) [Link] How about this:Introduce a 'computable' file.
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.
|
|||||||||||||