GTK Lands Meson Build System Support

[ebassi]

Autotools need just basic tools set and m4.

You mean:

- a shell
- awk
- sed, tr, grep, cut, wc
- make
- m4

at the least.

Plus, whatever each project requires to go through the build alone — likely Perl and/or Python, because not everything can be done sanely with a shell script.

The idea that autotools has "minimal dependencies" is a massive fallacy; by itself, yes, but any project using autotools unless it's ridiculously simple, will have additional build-only dependencies, or depend on something that has them.

Depending on Python3 alone is already a simplification of the build-only dependencies, compared to autotools.

[Brane215]

You mean:

- a shell
- awk
- sed, tr, grep, cut, wc
- make
- m4

at the least.

Plus, whatever each project requires to go through the build alone — likely Perl and/or Python, because not everything can be done sanely with a shell script.

The idea that autotools has "minimal dependencies" is a massive fallacy; by itself, yes, but any project using autotools unless it's ridiculously simple, will have additional build-only dependencies, or depend on something that has them.

Depending on Python3 alone is already a simplification of the build-only dependencies, compared to autotools.

F**k. You keep inventing new ways to play ignorant.
Autotools is not ideal, but shell|awk|sed|etc etc dependancy is hell of a lot simpler to work with than Python and its sstem of modules.
I don't remember last time bash died on me or some package croaked due to incompatible version of bash etc.

With Python, this was ubiqutous and still is far from rare occasions.

And even if, say tar died due to some rare glitch or glibc incompatibility, it isn't that big of a deal to recompile it. Hassle, yes, but for such rare occasion (if ever) it was quite tolerable.
After all, all those dependencies are quite mature and rarely change in incompatible way.

Python is OTOH movivign target. And when something inside breaks, good luck fixing it. And until you fix it, with your build systemd leaning on Python and its modules, you are going nowhere.

[Brane215]

Also don't mix project dependencies with build tool dependencies.


Buld tool dependecies are deeper, because they are connected to the system. If you screw package X dependency, big deal- so you'll have to roll your sleeves and check what's going on. If you fail, you'll still have a working system.

If you break build tool dependency, your are stuck in quicksand...

[Delgarde]

F**k. You keep inventing new ways to play ignorant.
Autotools is not ideal, but shell|awk|sed|etc etc dependancy is hell of a lot simpler to work with than Python and its sstem of modules.
I don't remember last time bash died on me or some package croaked due to incompatible version of bash etc.

He's right, though... non-trivial autotools builds often depend on a real scripting language somewhere in the process... usually Perl, but often Python.

[(tpm)]

Not to mention that it is also not uncommon for autotools builds to break or fail in mysterious ways because a script or Makefile snippet or configure snippet has been written for bash or does not work or behaves differently with dash or zsh or whatnotsh, or an older bash version. Or because some common 'standard' command line utility doesn't have a certain command line option or functionality on some version of some system.

[ikey_solus]

Not sure what you mean by many dependencies? When I do sudo pip install meson, it just installs Meson without any extra packages. Even on a clean Solus install. So either you're exaggerating or the amount of dependencies depends on the distro.

FWIW meson is in the Solus repos, we use it for building Budgie :P From what I can determine, meson has no external dependencies, it's just straight up Python 3 (I guess some distros might split python3 itself up into a lot of subpackages though. Still one source package as far as I'm concerned.)

[Vistaus]

FWIW meson is in the Solus repos, we use it for building Budgie :P From what I can determine, meson has no external dependencies, it's just straight up Python 3 (I guess some distros might split python3 itself up into a lot of subpackages though. Still one source package as far as I'm concerned.)

Yeah, I know it's in the Solus repos and I have it installed from the Solus repos, but thanks anyway But installing it from a distribution's repo is not exactly the best way to determine how many dependencies a package has, which is why I used the distro-agnostic PIP tool to see how many dependencies it has.

[ikey_solus]

Yeah, I know it's in the Solus repos and I have it installed from the Solus repos, but thanks anyway But installing it from a distribution's repo is not exactly the best way to determine how many dependencies a package has, which is why I used the distro-agnostic PIP tool to see how many dependencies it has.

Fair do :P I hate pip. Until I don't. Mostly do..

[Guest]

It doesn't help that you've named four projects that all have relatively unique builds... none of them fit the simple "./configure && make && make install" model either. From memory, Firefox and Libreoffice do use autotools, albeit not in any standard fashion - but Chromium and OpenJDK both use completely custom build processes...

Firefox uses it's own Mach build system which is quite a pain to configure, basically you have to create a definitions file which has all the flags that you want and that is fed to build system which decides what to do with it.