5 ms·

As an end user, I like how simple autotools is to build a project: ./configure && make && make install And I like that I can very easily see all the various

by rascul 5y ago

As an end user, I like how simple autotools is to build a project: ./configure && make && make install And I like that I can very easily see all the various build options: ./configure --help I don't like that configure takes a long time and checks things that don't seem like they really need to be checked. Nor do I like how difficult autotools is to use as a developer (I have some, but not much experience working on a project using autotools, over a decade ago). I've yet to see a competing build system that makes the end user usage and option discovery as simple. Edit: I've not necessarily used and explored all the various build systems, but the few I have used have generally not been as simple, or at least weren't to me obviously as simple.

downut 5y ago
I build a lot of cmake and meson projects. I was an expert at cmake for quite some time (bleh), but now I use meson for everything I can. The end user experience is in every aspect superior to autotools. There is a small downside for cmake compared to autotools: while you have to install the bits for autotools it runs on a shell. There is a bigger downside for meson: you need a minimal python infrastructure up and working. Over time you need that python infrastructure to keep working. Sometimes it doesn't. I still vastly prefer meson over cmake and much more so autotools. If I have to fix cmake or meson builds, well, really, if you know their languages, it's just no comparison to debugging the 1000s of lines of shell code autotools generates.
- rascul 5y ago
  I'm not very familiar with meson. I can use cmake to build a project but I don't know how to find various build options without searching through that project's documentation. I probably haven't explored cmake enough.
  - throwaway82652 5y ago
    Use cmake-gui and it lists all the options for you. Or for the manual method, search in the project's cmake sources for lines starting with "option(".
    - cycomanic 5y ago
      I would argue this confirms what the OP said cmake is really not very friendly to the user (not developer). Reading through the cmake sources for options is equivalent to "read the source".
      - jcelerier 5y ago
        But you only have to do this if you don't want to run an actual GUI or ncurses UI which does this for you for some reason ? What would you suggest instead ?
        cycomanic 5y ago
        Why do I need to run a gui or ncurses UI if I just want to do the equivalent of configure && make && make install?
        jcelerier 5y ago
        The equivalent of this is cmake -S source_folder -B build_folder cmake --build build_folder cmake --install build_folder You don't need to run a GUI at all for this, I don't see how you could infer this from the previous messages
        tpush 5y ago
        Something like 'cmake --list-options CMakeLists.txt' seems the most obvious.
        jcelerier 5y ago
        I don't think it would be meaningfully different from what you would get by doing less CMakeCache.txt Listing the options cannot be done by just introspecting a CMakeLists: what would it show for: if(FOO) option(ENABLE_BAMBOOZLE_${FOO} "Enable Bamboozle - ${FOO}-specific version" OFF) else() option(ENABLE_BAMBOOZLE "Enable Bamboozle" ON) endif() (and if your meta-build system does not allow to do that, I'm sorry but I'll have to build a meta-meta-build-system on top of it which implements it and no one will like it)
  - downut 5y ago
    In the build directory, "ccmake ." Note the "." I need to do this in almost every cmake project I don't know well. Also toggle on the advanced options listing. Occasionally you'll see stuff in the CMakeLists.txt files that don't show up in that menu. This is usually variables you can set on the command line to influence configuration. People are nowadays calming down their desire to program up their own flavor of a gigantic build system, and sticking to simpler idioms. That's a big improvement. However there's a lot of legacy nightmare cmake out there. Meson is much harder to build different dialects. Some people don't like this. After 35 years of build systems, I say yes please! I forget what I do in meson. Which means I just read the meson.build and meson_options.txt. They are quite straightforward, and very concise, if you're not Doing It Wrong.
- imron 5y ago
  meson is so nice to use.
- 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).
- pif 5y ago
  > it's just no comparison to debugging the 1000s of lines of shell code autotools generates If you find yourself debugging generated scripts, you have done something wrong.
  - CJefferson 5y ago
    I agree, but I have done things wrong with autotools, then spent hours debugging the generated scripts to figure out what I did wrong.
  - trasz 5y ago
    Not really - from my experience autotools can’t really be expected to work properly on any system it wasn’t tested on. And it’s way easier to hack the generated script - usually just commenting out the problematic part, as almost none of those scripts generated by autoconf serve any purpose.
flohofwoe 5y ago
The equivalent for a cmake project is roughly (from within a subdirectoy to not pollute the project directory with build files): cmake .. && cmake --build . && cmake --install . ...and discovering/changing the build options can be done interactively: ccmake . ...not that much different (and it usually works on Windows too). IMHO cmake for 'end users' (who just want to build a project into an executable) is mostly fine, it's just not great for the project maintainers because the cmake scripting language is a PITA.
badsectoracula 5y ago
The problem with Autotools isn't the end user experience, it is the developer experience - and guess who has all the power to make a build system choice? :-P IMO there needs to be a replacement for Autotools that from a user's perspective behaves exactly like Autotools (following the same GNU standards that specify how the configure script, etc is to be used, what parameters it accepts, etc) but provides a better experience for the developer.
- ilammy 5y ago
  My solution for C software that I maintain is handwritten ./configure of 200-ish lines of code, dealing with specific issues that I've encountered, supporting specific systems that are supported (Linux, macOS, Emscripten, MinGW). It looks and feels like Autotools script, outputs a file for make to include later, etc. If you're a user, familiar ./configure && make && sudo make install will do the trick for you. If you're a package maintainer, ./configure supports all the --libdir flags that packaging system sets, (handwritten) Makefile respects CFLAGS, DESTDIR, etc. All of it is extremely hackable since there are no silly layers of preprocessors between you and make. I guess the secret sauce here is having only OpenSSL as a dependency and the project being a fairly small library.
  - jonstewart 5y ago
    Uh could you throw that up on GitHub so I could shamelessly copy it? That sounds like a great technique.
- andoma 5y ago
  Check https://github.com/edenhill/mklove https://github.com/edenhill/mklove which aims to be a drop-in replacement of autotools but with sane developer experience.
marcosdumay 5y ago
Hum... Good thing you got a distribution package, and not a development one. From your comment, I expect you to have no idea what to do if you get a development package, as `configure` isn't even there. You just said that half of the procedure is simple enough. And then, I don't get your claim that nothing is comparable. For example, how is `cargo install` more complex than that? Or less discoverable? (Oh, and notice that there is no distinction between distribution and development packages for any other system, it's autotools only. Also, you may say "cargo is Rust-only", what is true, but autotools are C-only while pretending all over the docs that they are cross language.)

by rascul 5y ago

downut 5y ago

I build a lot of cmake and meson projects. I was an expert at cmake for quite some time (bleh), but now I use meson for everything I can. The end user experience is in every aspect superior to autotools. There is a small downside for cmake compared to autotools: while you have to install the bits for autotools it runs on a shell. There is a bigger downside for meson: you need a minimal python infrastructure up and working. Over time you need that python infrastructure to keep working. Sometimes it doesn't. I still vastly prefer meson over cmake and much more so autotools. If I have to fix cmake or meson builds, well, really, if you know their languages, it's just no comparison to debugging the 1000s of lines of shell code autotools generates.

rascul 5y ago
I'm not very familiar with meson. I can use cmake to build a project but I don't know how to find various build options without searching through that project's documentation. I probably haven't explored cmake enough.
- throwaway82652 5y ago
  Use cmake-gui and it lists all the options for you. Or for the manual method, search in the project's cmake sources for lines starting with "option(".
  - cycomanic 5y ago
    I would argue this confirms what the OP said cmake is really not very friendly to the user (not developer). Reading through the cmake sources for options is equivalent to "read the source".
    - jcelerier 5y ago
      But you only have to do this if you don't want to run an actual GUI or ncurses UI which does this for you for some reason ? What would you suggest instead ?
      - cycomanic 5y ago
        Why do I need to run a gui or ncurses UI if I just want to do the equivalent of configure && make && make install?
        jcelerier 5y ago
        The equivalent of this is cmake -S source_folder -B build_folder cmake --build build_folder cmake --install build_folder You don't need to run a GUI at all for this, I don't see how you could infer this from the previous messages
      - tpush 5y ago
        Something like 'cmake --list-options CMakeLists.txt' seems the most obvious.
        jcelerier 5y ago
        I don't think it would be meaningfully different from what you would get by doing less CMakeCache.txt Listing the options cannot be done by just introspecting a CMakeLists: what would it show for: if(FOO) option(ENABLE_BAMBOOZLE_${FOO} "Enable Bamboozle - ${FOO}-specific version" OFF) else() option(ENABLE_BAMBOOZLE "Enable Bamboozle" ON) endif() (and if your meta-build system does not allow to do that, I'm sorry but I'll have to build a meta-meta-build-system on top of it which implements it and no one will like it)
- downut 5y ago
  In the build directory, "ccmake ." Note the "." I need to do this in almost every cmake project I don't know well. Also toggle on the advanced options listing. Occasionally you'll see stuff in the CMakeLists.txt files that don't show up in that menu. This is usually variables you can set on the command line to influence configuration. People are nowadays calming down their desire to program up their own flavor of a gigantic build system, and sticking to simpler idioms. That's a big improvement. However there's a lot of legacy nightmare cmake out there. Meson is much harder to build different dialects. Some people don't like this. After 35 years of build systems, I say yes please! I forget what I do in meson. Which means I just read the meson.build and meson_options.txt. They are quite straightforward, and very concise, if you're not Doing It Wrong.
imron 5y ago
meson is so nice to use.
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).
pif 5y ago
> it's just no comparison to debugging the 1000s of lines of shell code autotools generates If you find yourself debugging generated scripts, you have done something wrong.
- CJefferson 5y ago
  I agree, but I have done things wrong with autotools, then spent hours debugging the generated scripts to figure out what I did wrong.
- trasz 5y ago
  Not really - from my experience autotools can’t really be expected to work properly on any system it wasn’t tested on. And it’s way easier to hack the generated script - usually just commenting out the problematic part, as almost none of those scripts generated by autoconf serve any purpose.

flohofwoe 5y ago

The equivalent for a cmake project is roughly (from within a subdirectoy to not pollute the project directory with build files): cmake .. && cmake --build . && cmake --install . ...and discovering/changing the build options can be done interactively: ccmake . ...not that much different (and it usually works on Windows too). IMHO cmake for 'end users' (who just want to build a project into an executable) is mostly fine, it's just not great for the project maintainers because the cmake scripting language is a PITA.

badsectoracula 5y ago

The problem with Autotools isn't the end user experience, it is the developer experience - and guess who has all the power to make a build system choice? :-P IMO there needs to be a replacement for Autotools that from a user's perspective behaves exactly like Autotools (following the same GNU standards that specify how the configure script, etc is to be used, what parameters it accepts, etc) but provides a better experience for the developer.

ilammy 5y ago
My solution for C software that I maintain is handwritten ./configure of 200-ish lines of code, dealing with specific issues that I've encountered, supporting specific systems that are supported (Linux, macOS, Emscripten, MinGW). It looks and feels like Autotools script, outputs a file for make to include later, etc. If you're a user, familiar ./configure && make && sudo make install will do the trick for you. If you're a package maintainer, ./configure supports all the --libdir flags that packaging system sets, (handwritten) Makefile respects CFLAGS, DESTDIR, etc. All of it is extremely hackable since there are no silly layers of preprocessors between you and make. I guess the secret sauce here is having only OpenSSL as a dependency and the project being a fairly small library.
- jonstewart 5y ago
  Uh could you throw that up on GitHub so I could shamelessly copy it? That sounds like a great technique.
andoma 5y ago
Check https://github.com/edenhill/mklove https://github.com/edenhill/mklove which aims to be a drop-in replacement of autotools but with sane developer experience.

marcosdumay 5y ago

Hum... Good thing you got a distribution package, and not a development one. From your comment, I expect you to have no idea what to do if you get a development package, as `configure` isn't even there. You just said that half of the procedure is simple enough. And then, I don't get your claim that nothing is comparable. For example, how is `cargo install` more complex than that? Or less discoverable? (Oh, and notice that there is no distinction between distribution and development packages for any other system, it's autotools only. Also, you may say "cargo is Rust-only", what is true, but autotools are C-only while pretending all over the docs that they are cross language.)