Hello, On Wed, 22 Nov 2017, Martin Vaeth wrote: >David Haller <gen...@dhaller.de> wrote: >> autotools is _by far_the best both from a users and a packagers view. > >I do not agree. Its main advantage is that it is compatible with >most existing unix systems (but I am already not so sure whether >this also holds if you also want to compile for windows, powerpc, >etc.)
Aye. >> cmake [...] qmake > >I agree, these are horrible. The best build system currently >appears to be meson. > >> equivalent to "./configure --help" > >For meson, it is "cat meson_options.txt", and there is a clear >distinction between general options and project specific ones. I've not yet "enconutered" meson... How is that meson_options.txt maintained? Automatically or by hand? If the former: yay! If the latter, treat it as non-existant... >> transparent and easily hackable > >Hacking autotools is a nightmare: Things are often hidden in >subprojects, sometimes combined with project specific hacks, >generating/updating necessary configure files somewhere within the >projects tree etc. Well, now you're quite exaggerating! Projects using subprojects with distinct autotools stack are broken by design and that is _NOT_ a fault of autotools. And it's not "often". And then, usually it's projects pulling in e.g. a "local" copy of e.g. "ffmpeg". _That_ is broken and a nightmare. But then again, it shows the "hackability" of autotools. With all "bad" side-effects. And on that I _DO_ agree quite affirmatively! But then again, nobody keeps devs from using local copies of qmake/cmake/meson/whatnot subprojects, in a otherwise autotools/cmake/qmake/meson project and you'll have the same horrors... >And after each change you have to run autoreconf, often with >compatibility problems of autoconf/automake/gettext/... versions etc. You'll get use to that. And you can get around by directly patching configure and Makefile.in files. It _IS_ up to you! And that's one of the points I like about autotools. You can even go around and first run ./configure and _then_ patch the Makefiles and whatever like the generated config.h. Or just set some ENV-vars or defines. That's the flexibility of autotools. You can choose quite exactly where you want to mess about with the delivered self-contained build. You can change (or "mess with") _ANYTHING AT ANY STAGE_ of the process. As bad as autotools are, that's something, I've not seen with any other build-system yet. Be they self contained (IIRC: bjam anyone?) or generators like imake/qmake, and cmake, what's that? It generates makefiles but ... *gah* >With meson, there is an absolutely strict separation between >the distributed files and the generated/output files which are >always in a fresh dir (and thus are _always_ produced). >When hacking up, you need to modify only the *.meson files >and do not have to worry about re-generating any other data. > >This sounds like I am a meson fanboy. I am not; actually, I dislike >a lot of its design decisions. But compared to autotools, cmake, >and qmake, it did a lot of things right. Welcome to the club of build-system-haters! :) I do not know meson yet, but, as far as I remember, it's rather "closed" to interference from "packagers". I think I will rectify my ignorance. But tell me: - can you influence large parts of the build by just using ENV-vars or easy options? 'DESTDIR="/foo"' is the prime example but doesn't count, that's _too_ obvious. With autotools, you're free to fiddle with any var in the generated Makefiles... - project specific './configure --help' (see above). Python's setuptools have that IIRC clumsily via 'python setup.py help' or some such, and that's usually rather disappointing regarding project specific options... - etc. pp. I'm to tired... As a packager, I just love autotools. As an author, autotools is a piece of cake (you need _very_ few lines in your configure.ac/Makefile.am, BTDT, esp. if you put your stuff into subdirs and can use make's wildcard function for source/header etc. stuff). Well, but plainly implemented, Makefile.am are just some few lines, with some clever "includes" (see the magic libreoffice does with "plain" makefiles) you could probably prune it down to 2-3 lines or so ... But! Yes, I will look into meson and try building one of my "fully autotooled" stuff as a meson project.. At least, I'll learn how to munge meson stuff to my liking :) I'm always curious about new build systems as a packager/ebuilder, and I had a case recently, where I got a build failure due to some build-system stuff, and I could not track it down. And I've about 15-20 years experience of compiling and packaging all kinds of weird stuff. But this time, no go. Until I acutally used 'strace -e file'! WHAT THE *FSCK*! ISTR it might have been cmake, pulling in some file from under /usr/. That's _NOT_ transparent. Debugging the build via strace? Hey? Anyone home? And no, no debug option did help. And when it comes to packageing, "I'm a Vet, I'm a Pro!" ;) [STR] Oh, and just running the good ole ./configure && make install has its charms ;) BTW: Has meson the seperation into "configure", "make/build" and "install" stages? ISTR it does .?.?.? -dnh PS: I hate how "sudo" is abused recently. But that's another rant. -- "What happens when you read some doc and either it doesn't answer your question or is demonstrably wrong? In Linux, you say "Linux sucks" and go read the code. In Windows/Oracle/etc you say "Windows sucks" and start banging your head against the wall." -- Denis Vlasenko on lkml