| |||||||||||||
add sh/bash to pain listadd sh/bash to pain listPosted Feb 22, 2007 0:00 UTC (Thu) by vmole (guest, #111)In reply to: add sh/bash to pain list by b7j0c Parent article: The Road to KDE 4: CMake, a New Build System for KDE (KDE.News)
Make is not painful, aside from the idiotic tab-only indent. (Notice that cmake still relies on make). Make works fine, especially the GNU version.
What is painful is the standard GNU build system with recursive Makefiles, autoconf (wrong-headed, but livable), automake (bad), and the-tool-that-shall-not-be-named (okay, I'll write it: libtool. Watch out for the Shoggoth).
There's a lot of inertia in Unix tools because most of the tools work just fine. The trouble is that leads some to believe they're all good...
(Log in to post comments)
add sh/bash to pain list Posted Feb 22, 2007 1:25 UTC (Thu) by ajross (subscriber, #4563) [Link] I agree wholeheartedly. Make is simple and easy, with really just one true design flaw (whitespace-sensitive syntax). But it doesn't solve the whole problem: in particular, it doesn't provide any built-in support for portable build schemes or compile-time configuration management.
So a whole bunch of other crap gets layered on top, with varying degrees of success (autotools, despite the mind-twisting weirdness, at least has the advantage of being quite featureful and *very* widely supported). And the resulting complexity leads the community to declare "make sucks!".
And thus is spawned an unending stream of make-like build systems, most of which don't do much more than fix the whitespace-sensitive syntax. Not that this necessarily applies to CMake, about which I know nothing. If I had to pick a target for this flame, I'd choose Ant or SCons...
add sh/bash to pain list Posted Feb 22, 2007 3:39 UTC (Thu) by b7j0c (subscriber, #27559) [Link] > Make is simple and easy, with really just one true design flaw> (whitespace-sensitive syntax)
you don't count its reliance on build file timestamps as a design flaw?
add sh/bash to pain list Posted Feb 22, 2007 3:57 UTC (Thu) by ajross (subscriber, #4563) [Link] you don't count its reliance on build file timestamps as a design flaw? Um, no? Sorry, but I guess I don't understand your thinking here. Automatically tracking dependencies and rebuilding targets that depend on "changed" files is, I think, an unarguably useful feature. And it inherently requires that there be some mechanism for telling when a file has changed. Now, certainly there are many mechanisms for tracking that information. But given that make is using the one provided by the operating system, I fail to see why any of the alternatives would be preferable.
add sh/bash to pain list Posted Feb 22, 2007 5:45 UTC (Thu) by b7j0c (subscriber, #27559) [Link] > 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) [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.
make shmake Posted Feb 22, 2007 6:31 UTC (Thu) by ldo (subscriber, #40946) [Link] Make is not painful,... Yes it is. The only kind of dependency it can express is a build-dependency. No provision for expressing other things, like include-dependencies. Hence the need for layering all kinds of other cruft on top to get around this limitation.
make shmake Posted Feb 22, 2007 12:54 UTC (Thu) by nix (subscriber, #2304) [Link] Per-language dependency analysis plugins to make would be nice, I agree, probably conditionalized on pattern rules, e.g
%.c %.h: $(dependency-plugin c)
which loads, say, /usr/libexec/make/dependencies/c.so with a defined interface and uses it to append dependencies to .c and .h spotted in target lists...
make shmake Posted Feb 22, 2007 19:32 UTC (Thu) by oak (subscriber, #2786) [Link] > The only kind of dependency it can express is a build-dependency.> No provision for expressing other things, like include-dependencies. As you found out, Make is not supposed to be a/b/c/d/e/f-language pre-processor. You ask that kind of information from the compiler of the corresponding language. With C-language and GCC compiler you could use a rule like this:
# automatic include file dependencies
deps: $(SRCFILES)
gcc $(CPPFLAGS) -MM $^ > deps
-include deps
make shmake Posted Mar 1, 2007 19:54 UTC (Thu) by nix (subscriber, #2304) [Link] It would be nice if that sort of boilerplate could be generalized outsomehow. Mega-duplication (or the reliance on system-specific stuff like *BSD makefile fragments) both are nasty...
make shmake Posted Mar 2, 2007 23:33 UTC (Fri) by ldo (subscriber, #40946) [Link] Jam already has this sort of thing built-in. So much simpler than trying to add yet another layer of complexity on top of make.
make shmake Posted Mar 5, 2007 13:42 UTC (Mon) by nix (subscriber, #2304) [Link] jam strikes me more as a language to build build systems in than a build system.
I remember trying to set the equivalent of CFLAGS and prefix with Boost... it took a couple of dozen lines of patches to the build system just to do that, and a couple of patches to the jam source bundled with Boost.
Sorry, but I prefer Automake's nasty verbose makefiles to *that*.
add sh/bash to pain list Posted Feb 22, 2007 8:22 UTC (Thu) by lamikr (guest, #2289) [Link] I agree, make itself is not bad at all.More proplematic things happens usually when you need to modify for example "configure.in" files to be able to get changes to "configure" file.
(For example to get rid from the "build and run test" for a certain library. This is quite common if you are using cross-compiler, because then the test executable can not usually be executed in the host computer where the build is performed.)
|
|||||||||||||