Re: [gentoo-user] Re: is multi-core really worth it?

[David Haller]

Hello,

On Wed, 22 Nov 2017, Martin Vaeth wrote:
>David Haller <gentoo@×××××××.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