2 ms·

And yet, meson just routinely doesn't work. Sure: if you are just trying to do some trivial local compile job it seems fine, but it keeps having issues with eve

by saurik 5y ago

And yet, meson just routinely doesn't work. Sure: if you are just trying to do some trivial local compile job it seems fine, but it keeps having issues with even trivial cross compilation cases (which are used even on Linux as you generally want to do a Linux-to-Linux cross compile to control your glibc target) and linker detection (as it is assuming way too much direct control over the linker that it should frankly be delegating to the compiler) that make you have to jump through ridiculous hurdles to make things compile (and that's assuming you aren't on one of the commonly-deployed semi-recent versions of meson where it is a truly lost cause). In contrast, autotools always works: I have never had a blocking or serious issue compiling something that uses autotools, no matter how complex the scenario. Here are a couple issues I have run into (one being fixed, though too late for some key versions of Ubuntu; and the other just languishing, as I guess "working" is asking for too much). https://github.com/mesonbuild/meson/issues/6057 https://github.com/mesonbuild/meson/issues/6057 https://github.com/mesonbuild/meson/issues/6662 https://github.com/mesonbuild/meson/issues/6662

downut 5y ago
Could be; I'm not an evangelist for meson and if it doesn't work for cross compilation I'd use something else, likely cmake. I don't cross compile very often, so for me it works great. I have run into sadness with meson subprojects, but I'm unconvinced they are a big win.
- saurik 5y ago
  The problem is that I don't get to make the decision to use meson or cmake: you make that decision when you develop your project around meson; which ties back to the point of this thread: as a user attempting to compile something (which FWIW should essentially always be a cross compile... a native compile is essentially never what you want as it bleeds way too much random machine state into your build), autotools is still king (and certainly much better than the haphazard piles of programmable cmake that people tend to throw together when they use cmake; at least with cmake,npeople tend to develop stuff where I just give up on their compilation scripts and compile all their code with my own replacement scripts... sadly, I haven't managed to do that reasonably for glib yet so I could avoid their meson hell).
  - jameshilliard 5y ago
    For us(https://buildroot.org/ https://buildroot.org/) cross compiling with meson tends to be significantly more reliable than autotools already as it tends to be much better at separating host/target artifact builds within a project and setting up the toolchain correctly, autotools tends to need lots of package specific hacks in my experience. We have a fairly customized integration(https://github.com/buildroot/buildroot/blob/master/package/pkg-meson.mk https://github.com/buildroot/buildroot/blob/master/package/p...) which we've iterated on for a while that works quite well these days. The cross compilation support with upstream meson has improved a lot over the years and while it's quite mature now IMO it still takes a bit of env setup to work correctly(but once it works it tends to not break much).
bonzini 5y ago
For the second, https://github.com/mesonbuild/meson/issues/6662#issuecomment-763958061 https://github.com/mesonbuild/meson/issues/6662#issuecomment... is the right solution and I will try to have it documented. Unfortunately, clang disagrees that it's the right solution and meson might have to hack something around that disagreement. Thanks for the report!
marcosdumay 5y ago
Hum... Configure routinely doesn't work for me either, on even more trivial scenarios than cross-compilation. When I care to look how to fix it, it's almost always some error on the autotools configuration and I can edit the Makefile to run things correctly. Also, when it breaks, there are normally more broken things on the project. But autotools are always among the first things to break.
- teknopaul 5y ago
  Is autotools the first to break or the first that you notice and fix ;)
  - marcosdumay 5y ago
    It is a very good predictor of breakage anywhere. Code where the autotools are perfectly configured normally is very close to correct. It's usually not broken on my own code because I will write a DAG builder in bare C before I use them personally, so I don't know the breakage timing.

by saurik 5y ago

downut 5y ago

Could be; I'm not an evangelist for meson and if it doesn't work for cross compilation I'd use something else, likely cmake. I don't cross compile very often, so for me it works great. I have run into sadness with meson subprojects, but I'm unconvinced they are a big win.

saurik 5y ago
The problem is that I don't get to make the decision to use meson or cmake: you make that decision when you develop your project around meson; which ties back to the point of this thread: as a user attempting to compile something (which FWIW should essentially always be a cross compile... a native compile is essentially never what you want as it bleeds way too much random machine state into your build), autotools is still king (and certainly much better than the haphazard piles of programmable cmake that people tend to throw together when they use cmake; at least with cmake,npeople tend to develop stuff where I just give up on their compilation scripts and compile all their code with my own replacement scripts... sadly, I haven't managed to do that reasonably for glib yet so I could avoid their meson hell).
- jameshilliard 5y ago
  For us(https://buildroot.org/ https://buildroot.org/) cross compiling with meson tends to be significantly more reliable than autotools already as it tends to be much better at separating host/target artifact builds within a project and setting up the toolchain correctly, autotools tends to need lots of package specific hacks in my experience. We have a fairly customized integration(https://github.com/buildroot/buildroot/blob/master/package/pkg-meson.mk https://github.com/buildroot/buildroot/blob/master/package/p...) which we've iterated on for a while that works quite well these days. The cross compilation support with upstream meson has improved a lot over the years and while it's quite mature now IMO it still takes a bit of env setup to work correctly(but once it works it tends to not break much).

bonzini 5y ago

For the second, https://github.com/mesonbuild/meson/issues/6662#issuecomment-763958061 https://github.com/mesonbuild/meson/issues/6662#issuecomment... is the right solution and I will try to have it documented. Unfortunately, clang disagrees that it's the right solution and meson might have to hack something around that disagreement. Thanks for the report!

marcosdumay 5y ago

Hum... Configure routinely doesn't work for me either, on even more trivial scenarios than cross-compilation. When I care to look how to fix it, it's almost always some error on the autotools configuration and I can edit the Makefile to run things correctly. Also, when it breaks, there are normally more broken things on the project. But autotools are always among the first things to break.

teknopaul 5y ago
Is autotools the first to break or the first that you notice and fix ;)
- marcosdumay 5y ago
  It is a very good predictor of breakage anywhere. Code where the autotools are perfectly configured normally is very close to correct. It's usually not broken on my own code because I will write a DAG builder in bare C before I use them personally, so I don't know the breakage timing.