Mesa Developers Move Closer To Dropping Autotools Build System In Favor Of Meson

[rene]

meson has 786 open issues, so raised bug is unlikely to be served soon
i know ridiculous bug of combinatorial explosion of library parameter lists ( -l and -L ) generating ninja file of several gigabytes size for project with few dozen of dependencies and i decided to work it around by unfolding every dependency instead of reporting it

Did not even know that hard fact, but if true it certainly makes it the best, and maybe fastest several gigabyte generator out there, … well, maybe at least closely followed by dd=/dev/zero, … ;-

[rene]

in autotools make is not the slowest part. slowest part is shell configure.

That and calling the compiler for testing gazillion, often unnecessary nonsense. I do not use any of this in my projects, and simply use things like sizeof(int) and such in the code that just magically works everywhere, instead of HAVE_THIS, SIZEOF_THAT, … configure problem fixed naturally, ..! ;-)

[shmerl]

that one needs to read other distributions scripts / config and examples does not even make this meson stuff to be so easy, natural, and most awesome to use, … :-/

Meson is better than autotools. But Mesa is a monster of a project, and figuring out how to configure it is hard no matter what you use. So why not use what distros already figured out?

[s_j_newbury]

That and calling the compiler for testing gazillion, often unnecessary nonsense. I do not use any of this in my projects, and simply use things like sizeof(int) and such in the code that just magically works everywhere, instead of HAVE_THIS, SIZEOF_THAT, … configure problem fixed naturally, ..! ;-)

That isn't really an alternative. How can you make pre-processor based decisions on code inclusion using sizeof()? For simple things it's fine, and the compiler takes care of generating correct code, but there are many cases where that isn't optimal at all.

[Weasel]

That isn't really an alternative. How can you make pre-processor based decisions on code inclusion using sizeof()? For simple things it's fine, and the compiler takes care of generating correct code, but there are many cases where that isn't optimal at all.

It won't even compile in most cases.

[Jabberwocky]

C/C++ is perhaps one of the worst languages for writing software, and the least maintainable . Every large C project has had major security problems.

I have always admired the simplicity of C. Not a fan of C++ although I understand why it's popular.

if Python could support backwards compatibility it would be far, far better than C or C++

Are you smoking your socks? (I don't know how Python can be compared directly to C/C++ across the board, apples and oranges)

When Python 3 came about, they should have committed to backwards compatibility, at least having a compiler for Python 2 that can run on the same VM as python 3 and allow them to share dependandancies. i question the philosophy behind Python making a breaking change to the language.

How do you provide backwards compatibility for this?

I also disagree with Python in numerous other instances in the manner it imposes politically driven restrictions such as the lack of increment operator and its jingoist attitude on goto, that because someone made some witty comment about goto, that goto is bad. People just parrot that over and over again, its like how they parrot X is bloated or whatever. There is nothing wrong with goto an goto code can be completely readable, in some cases better than structured conditionals. So I do not appreciate Pythons condescending attitude. Its important to note the whole point of a language is syntax sugar. If a language was not supposed to have syntax sugar, we would just code in in binary, If your not coding in binary, your using syntax sugar. Despite Python is head and shoulders above C.

I understand the usage of goto in some places in C, for example: https://github.com/torvalds/linux/bl...re/dev.c#L1640 but saying that structured programming in high level languages like Python is bad. That I can not understand. If you want to explain it, I'm open to learning or gaining a different perspective.

I however prefer Perl and its philosophies.

TLDR; Ironically Perl's philosophies prevents it from being a pragmatic candidate for large system, web, and application programming projects. That's not to say that it's not possible to use Perl of previously mentioned projects, look at PHP and it's accomplishments.

I came to the following conclusion after using Modern Perl for 3 years (full-time): In order to be an acceptable Perl programmer you need to check a lot of boxes.

Few examples:

• Without a shadow of a doubt need a lot of programming experience preferably in more than one language prior to learning Perl. You should never learn about thread safety and OOP for the first time using Perl as a foundation.
• Patience when frequently reading loads of bloated documentation and spaghetti code (it's not unheard of to find people that actually enjoy this).
• The unopinionated syntax and coupling with shell gives great flexibility and allows you to solve small problems very quickly using the arsenal of potentially redundant and non-portable built-in utilities offers. If you lack the tiniest bit of self-control or assumed-knowledge in Perl or the domain-specific language or your team choose to embed it could mean the end of you and or your project.
• Attention to the smallest detail introduced by syntax sugar and super-human-skill to write close to perfect (secure) code before completing your task/module. Debugging is something you want to avoid at all cost as it's much more expensive due to the amount of variables and lack of tooling.
• Independent, this is probably the most important. If someone does not think the same way as you or have the exact same idea, then it can lead to all sorts of problems.
• You need to be able to bless cows, okay this was just a joke! 8-)

You might read this and think, sure that's what all programmers need. The relativity of these concepts are also very important. Some of the top software companies in the world can't use something as relatively opinionated like Javascript and they call their software: "Ultra Fast", "Mega Secure", and "Super Reliable". It has been proven over and over in reality not all programmers (especially junior) have these attributes and all people make mistakes.

Diminishing returns comes quicker than expected when your project grows and you need to maintain backwards compatibility. Popularity is obviously also a problem when you depend on community maintained libraries, but that's a given with any language. It's just that Perl is becoming less popular as we are using libraries instead of applications and keep moving further away from text based interfaces like /dev/tty232.

I find Golang is best language for high level non-system programming for large projects. Typescript comes close, just not as practical unless you are doing "web" development.

Edit: Python is an awesome scripting language, easy to learn and seems to keep gaining popularity in various industries (financial, biology, data-science, etc). I know many big companies that use it successfully in big projects too. There are many solutions out there.

Back on topic: I have not used meson yet, looking forward to trying it out.

[SystemCrasher]

That's sucks for the real. If that happens, okay, it would be one less dude who builds that thing and gives it a try. Just because I do like autotools and do not get point of meson, that sucks badly enough to fail to generate makefiles, demands python (and I'm fed up with all that incompatible python versions tantrum, for the real) and demands me to install some super-duper ninja. For what exactly? I never spotted "make" as bottleneck. OTOH python is a major system trouble on the way.

And if devs want to throw something away, why not drop SCons instead? That one even worse than Meson, actually I'm yet to see more awkward build system. Autotools on other hand are mature and at least would detect and report configuration issues in more or less sane manner in each and every strange configurataion. Unlike these weird wannabe-buildsystems solving unknown problems and not being really helpful in actually building & configuring things. What the hell is going? Has this world gone crazy? Or what?

[SystemCrasher]

As for python being "far, far better" than C - uhm well, have fun trying to generate code that is optimized anyhow comparably to C code. Somehow whole language design is actively hostile to it, just like JS, etc. Furthermore, it invoves some non-trivial features like dynamic types or even eval(). That makes runtime environment fragile, hazardous and unpredictable overall. So it would be awful choice when reliability is needed. Somehow all python things I've seen were only working when situation is perfect, and even then they could backfire in crapload of unexpected ways, be it wrong python version or just some error silently ignored somewhere but breaking program execution later - and of course one gets no any sane diagnostics - so good luck to troubleshoot it.

[smitty3268]

That's sucks for the real. If that happens, okay, it would be one less dude who builds that thing and gives it a try. Just because I do like autotools and do not get point of meson, that sucks badly enough to fail to generate makefiles, demands python (and I'm fed up with all that incompatible python versions tantrum, for the real) and demands me to install some super-duper ninja. For what exactly? I never spotted "make" as bottleneck. OTOH python is a major system trouble on the way.

Just give it a try and see the performance difference yourself. Hint: it's not make itself that tends to be the slow bit in a build. You should also check out the actual scripts that are used to maintain the build, and compare the autotools vs Meson ones, and ask yourself which is easier to understand and less code for devs who really don't want to think about the build system at all.

And if devs want to throw something away, why not drop SCons instead? That one even worse than Meson, actually I'm yet to see more awkward build system.

They do plan to do that as well. Right now it's used by VMWare for their Windows builds, so they need to sign off and port their tools/build machines/etc. over to Meson before that happens. Since the Intel devs are driving this and mostly using it on Linux, autotools is the first build system they got around to replacing. It sounds like Android might be more of an issue, so that build system may stick around as separate.

Autotools on other hand are mature and at least would detect and report configuration issues in more or less sane manner in each and every strange configurataion. Unlike these weird wannabe-buildsystems solving unknown problems and not being really helpful in actually building & configuring things.

If you are aware of anything that the new build system doesn't do that the old one did, I'm sure Mesa would like to hear about it.

[SystemCrasher]

I never had major problems with build system performance. In small projects it just not a big difference if it would be 1 second or two. In large things with huge code it would be compiler that spends most time anyway, to generate reasonably optimized code.

So no. Fuck no. No way I would ever use python shit to build C things. Not a snowball chance in the hell. I'm already fed up seeing how debian testing moves to python 3.6 just to find it is already time to go 3.7, and some software wasn't even rewritten from 2.x series. So one can eventually figure out they need like 3-4 python runtime versions at once. Honestly, I had enough of this and I can't readily name any other language worse in this regard. So if some program demands python it can count on my middle finger, any day. That's what I tried for sure, it worked - and saved me plenty of my brain cells from dealing with all this python versioning tantrum and so on.

As for speed, look, autotools do work in weirdest configurations. And can at least give more or less human-comprehensible error message telling me what's wrong and what I lack. Somehow Meson isn't like this at all. Maybe that's why it fast. However I do not really get what problem it solves in first place. Autotools allow one to ensure their thing builds on nearly any crazy configuration people on planet can have. Or at least it would tell them what they have to change. Meson isn't like this at all. And if it would ever get anyhow comparable to autotools in regard of diverse platforms and environments support, it would have to do equally huge number of strange checks for all bizarre things. At which point its performance would hardly be better.

I already seen how it works on clang example. Fast compile times? Yay! Oh, wait, code isn't optimized. Let's improve that! What? Now it even slower than GCC?! Haha, software development is all like this.

Whatever. I would rather die than use python for C software development. I like C. Python is the very opposite of what I like about C.

They do plan to do that as well. Right now it's used by VMWare for their Windows builds, so they need to sign off and port their tools/build machines/etc.

VMWare ppl are really strange. They use awkward build system, target weid compilers, that can't even do C99 and looking on all that... the only idea I can get is that it really sucks to be windows developer .

Speaking for myself, if ppl are so eager to replace autotools, they can count on this breaking my workflows, so I would just give up on this and would no longer give a try to preliminary MESA versions. So I don't have to deal with all this meson, python and so on. Some maintaners could undertake this pain if they want to, but I'm out. Let RH nuts do it instead, they are at least paid for all this unpleasant shit.