6 ms·

> Which makes me think... why did I just sit through that long "configure" script run, and why did the developer bother messing with autotools, if this project

> Which makes me think... why did I just sit through that long "configure" script run, and why did the developer bother messing with autotools, if this project isn't even going to bother targeting anything but Linux with the GNU toolchain to build it? Even if target is just Linux with GNU toolchain, there are still plenty of issues that needs to be managed by configure script - tests for mandatory and optional libraries / header files, some functions are in different libraries on different systems (e.g. tinfo vs ncurses, or librt), different versions of kernel headers, different versions of GCC (older ones may not support some options).

enriquto 6y ago
> tests for mandatory and optional libraries I never understood the concept of "optional" library. Either your program requires a library or it doesn't. If it requires the library, the easiest thing to do is to assume that it is already installed and just link to it. In case it is not installed the compiler will fail with a very clear error message. Say, your program is an editor of png files and it requires libpng. Thus in your code you will have #include <libpng.h> and in your makefile you will link your executable with -lpng. And that is all! This works in linux, bsd and macOS. What the fucking else do you need?
- throwaway9d0291 6y ago
  Sure, it can be simple. To give you a less clear example, think about writing a library that sends telemetry to some cloud service. The telemetry could be readings from a sensor attached to a microcontroller with 512K of RAM or it could be readings from a server sitting in a datacenter with 256GB of RAM. You need some helper library to handle the protocol and there's a really nice full-featured library that comes with a bunch of handy debugging tools but it's too memory-hungry for that tiny microcontroller. Another option is a minimalist library that uses very little memory but also has less flexibility in say TLS. If you pick just one, one of your platforms ends up suffering needlessly. Adding the options allows the user to decide what's best for them.
  - enriquto 6y ago
    Sure, you can have different make targets if you really need to. Or Makefile.linux and Makefile.embedded everybody understands what to do in that case. I simply don't understand the explosion of complexity associated to autotools, cmake, and the like.
    - rcxdude 6y ago
      Because the cartesian product of options quickly explodes and you're suddenly managing 256 targets or makefiles (though even in Make there's a better way to handle this, though it's made painful by the syntax). It's very common for larger pieces of software to have 30-50 different configuration options for building.
    - db48x 6y ago
      It's not just about libraries. Autoconf for example can abstract across different compilers from different vendors, with all their various incompatible command–line arguments. And it does that for a dozen or so different languages, not just C. It can abstract across different function signatures in the libraries you're using. For example if you're calling a libc function where the arguments have changed, you can detect which version of the function you have and make your code work with either one. It can do the same for structs and types as well. It can test for system services, such as X Windows or the ability to run Perl scripts. It can abstract over the differences between different implementations of common utility commands such as awk, grep, install, mkdir, and so on. It does a lot of stuff!
      - enriquto 6y ago
        > It does a lot of stuff! Of course it does. My point was that I've never found it did anything that I was interested in.
        db48x 6y ago
        Then it wasn't written for you. It was written for people who want to distribute software to users who do not all run the same Unix operating system (not to mention the radically incompatible hardware of the day), and whose Unix vendors are all mutually hostile to any form of cooperation with each other. If all you ever install your software on is Ubuntu running in a VM at your cloud provider, then of course this will all be irrelevant to you.
- dagw 6y ago
  Say, your program is an editor of png files Say you are writing a program to edit images that can potentially read lots of different formats. However most people don't need support for .sgi or .ecw files and won't have the libraries to read those formats installed. Your program is still perfectly usable without those libraries and so you should still be able to compile and run it, just without support for those formats.
  - mrmonkeyman 6y ago
    I like the idea, but the reality is that it fosters extreme complexity on all kinds of axes for marginal benefit. Sure, for hobbyists it is fine but professional use.. I disagree.
  - user-the-name 6y ago
    Then you end up with a program where the users can never trust it to have any given feature. They use it all the time to edit .sgi files, and then install it on a new computer, and bam, suddenly, no support for .sgi files. Or even worse, it is used as a dependency in a script, or it is a library linked by another program, but the author can never trust that any given installation has the feature he actually needs. It is a mess. Just don't do it.
    - amelius 6y ago
      Exactly. By the way another thing I've come to hate is configure or make scripts which download stuff. This is really annoying if you want to build self-contained packages. Or if the downloaded material ends up being not available, or if you're not always connected to the internet.
    - AshamedCaptain 6y ago
      The disadvantage is very mild, and the advantage huge (modularity and ability to easily go embedded). If your dependency manager cannot express "program[+feature]", it is your dependency manager's problem.
      - 6y ago
- bayindirh 6y ago
  > I never understood the concept of "optional" library. Consider a scientific software, let's call it x. x can solve many problems and these problems cross-cut a lot of disciplines. A researcher, user of x has a need for only subset of these features, and configures & compiles x with the features only he/she needs. This has many advantages from simpler setup to shorter build to easier verification. When you're compiling software on remote, restricted systems; these optional components makes people's life a lot easier. Also, esp. in scientific community, every library needs something lower level so, trying to compile everything in results in exponential dependency hikes. Optional components solve this very neatly.
  - dagw 6y ago
    Another similar use case that is quite common is that your tool can use one of several different calculation kernels. For example there is one option that is fast but closed source, one that is open source but slower and one option that only works with Nvidia GPUs. Most people won't have all three options available, but as long as you have one of them the software works fine.
- josefx 6y ago
  One of the frameworks I use optionally supports a commercial library. If the library is present it enables support, if it isn't it just compiles without it. This is a nice feature since it avoids a lot of manual configuration. The downside is that support fails silently if the library is missing - since that is the expected case for most users.
- jononor 6y ago
  And what if your program needs a version of libpng above a certain version? And maybe below another one? That can give compile errors that are quite alot harder to grok.
- jasode 6y ago
  >I never understood the concept of "optional" library.[...] In case it is not installed the compiler will fail with a very clear error message. [...] and in your makefile you will link your executable with -lpng. And that is all! This works in linux, bsd and macOS. What the fucking else do you need? Interesting condescending tone there. I didn't downvote but if I can try to answer the core part of your misunderstanding: Many do _not_ want the build to fail when library png is missing. Example projects using this type of build optionality are FFmpeg and Qt. For example, ffmpeg lets you build with the optional Fraunhofer FDK AAC (libfdk_aac)[1] encoder but it is not GPL license compatible. If everyone followed your "assume libfdk_aac is already installed" advice, many people would be stuck at the "very clear error message" and not be able to have a working GPL ffmpeg. Same idea with Qt optional libraries. [1] https://trac.ffmpeg.org/wiki/Encode/AAC https://trac.ffmpeg.org/wiki/Encode/AAC
  - kgwgk 6y ago
    Come on, then just edit a configuration file specifying what libraries you want to use and where they are! /s
    - matthewaveryusa 6y ago
      Ok, humor me for a second: What's wrong with that?
      - kgwgk 6y ago
        It's not "wrong". It's a choice. You can provide some code and let the users do whatever is needed to get it to compile on their system. Or you can try to automate the process with the best of intentions and create a monster. In any case, the reason why autotools exists in the first place is that people were less than thrilled with the work required to make things work by hand.
        twic 6y ago
        Users should ask for something, and the build should build that, or fail if it can't. Randomly linking against things if they happen to be available is a terrible idea. Does any build ecosystem except C do this? I'm not sure even CMake does this.
- wheels 6y ago
  Large projects can take dozens of minutes up to hours to compile. It's extremely frustrating if the build system doesn't tell you in advance if it expects the compile to work. Having an error message once every 20 minutes, adding a package and restarting the build is terrible. (Also, for package systems like DEB or RPM, you can't just continue a compile that half-finished.) Now imagine you're a Linux distro and doing that for thousands of packages...
  - enriquto 6y ago
    > It's extremely frustrating if the build system doesn't tell you in advance if it expects the compile to work. I have only found this behavior in three different projects that used cmake. After several minutes of beautiful compilation lines in green, it turns out that the library (that cmake was supposed to check) was not installed after all. Of course it printed a beautiful error message in red. Beautiful but non-informative, that is.
- zajio1am 6y ago
  > I never understood the concept of "optional" library. Either your program requires a library or it doesn't. The program may have an optional feature that requires a library. It does not make sense to force everyone to install it, if such feature is used by 1 % of users. Example might be mplayer, where there are common decoding libraries used by everyone and also plenty of obsure decoding libraries. Even better is to use dlopen() to open the optional library in runtime, to fit in distribution package management paradigm, but this requires much more work than simple option to disable dependency at compile time, and even with it it is useful to have ability do disable optional dependency at compile time to avoid requiement for header files.
- zajio1am 6y ago
  > Say, your program is an editor of png files and it requires libpng. Thus in your code you will have > > #include <libpng.h> In addition to what other commenters wrote (failures later during compilation instead of at the start), you also need proper include path in CFLAGS. For example, gdk-pixbuf is supposed to be included by '#include <gdk-pixbuf/gdk-pixbuf.h>'. That would assume the header file is in /usr/include/gdk-pixbuf/gdk-pixbuf.h . But distribution that i use installs it in /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h , likely to be able to have multiple versions of header files installed togethers. You are supposed to use 'pkg-config' tool in configure script to add proper header file locations in CFLAGS to handle this (in this case -I/usr/include/gdk-pixbuf-2). > and in your makefile you will link your executable with -lpng. The library you are usimg may depend itself. on another library, you need to add -l flags for all recursively dependent libraries to linker. As this set of recursively dependent libraries may change in the future, you are supposed to use pkg-config to find proper link flags. Note that all of this is not really dependent on configure, you can do that in a simple makefile (by just calling pkg-config directly from it). So it is more about using pkg-config instead of hardcoded paths than about using configure scripts.
  - enriquto 6y ago
    > proper include path in CFLAGS This makes no sense. Preprocessor options have no place in CFLAGS, which is for compiler options. I guess you meant CPPFLAGS? Putting a preprocessor option on CFLAGS is always wrong and expected to fail. > But distribution that i use installs it in If your distribution installs headers outside of the preprocessor path (or somewhere inside CPATH or C_INCLUDE_PATH), then I'd say that this distribution is broken: it has not installed the library, just copied the files somewhere. The makefile is then, correctly, expected to fail. It's just as if you had unzipped the library on /tmp, of course you would not expect the compiler to find it!
    - pjmlp 6y ago
      This kind of opinions is why the dream of Desktop Linux will keep being a dream.

enriquto 6y ago

> tests for mandatory and optional libraries I never understood the concept of "optional" library. Either your program requires a library or it doesn't. If it requires the library, the easiest thing to do is to assume that it is already installed and just link to it. In case it is not installed the compiler will fail with a very clear error message. Say, your program is an editor of png files and it requires libpng. Thus in your code you will have #include <libpng.h> and in your makefile you will link your executable with -lpng. And that is all! This works in linux, bsd and macOS. What the fucking else do you need?

throwaway9d0291 6y ago
Sure, it can be simple. To give you a less clear example, think about writing a library that sends telemetry to some cloud service. The telemetry could be readings from a sensor attached to a microcontroller with 512K of RAM or it could be readings from a server sitting in a datacenter with 256GB of RAM. You need some helper library to handle the protocol and there's a really nice full-featured library that comes with a bunch of handy debugging tools but it's too memory-hungry for that tiny microcontroller. Another option is a minimalist library that uses very little memory but also has less flexibility in say TLS. If you pick just one, one of your platforms ends up suffering needlessly. Adding the options allows the user to decide what's best for them.
- enriquto 6y ago
  Sure, you can have different make targets if you really need to. Or Makefile.linux and Makefile.embedded everybody understands what to do in that case. I simply don't understand the explosion of complexity associated to autotools, cmake, and the like.
  - rcxdude 6y ago
    Because the cartesian product of options quickly explodes and you're suddenly managing 256 targets or makefiles (though even in Make there's a better way to handle this, though it's made painful by the syntax). It's very common for larger pieces of software to have 30-50 different configuration options for building.
  - db48x 6y ago
    It's not just about libraries. Autoconf for example can abstract across different compilers from different vendors, with all their various incompatible command–line arguments. And it does that for a dozen or so different languages, not just C. It can abstract across different function signatures in the libraries you're using. For example if you're calling a libc function where the arguments have changed, you can detect which version of the function you have and make your code work with either one. It can do the same for structs and types as well. It can test for system services, such as X Windows or the ability to run Perl scripts. It can abstract over the differences between different implementations of common utility commands such as awk, grep, install, mkdir, and so on. It does a lot of stuff!
    - enriquto 6y ago
      > It does a lot of stuff! Of course it does. My point was that I've never found it did anything that I was interested in.
      - db48x 6y ago
        Then it wasn't written for you. It was written for people who want to distribute software to users who do not all run the same Unix operating system (not to mention the radically incompatible hardware of the day), and whose Unix vendors are all mutually hostile to any form of cooperation with each other. If all you ever install your software on is Ubuntu running in a VM at your cloud provider, then of course this will all be irrelevant to you.
dagw 6y ago
Say, your program is an editor of png files Say you are writing a program to edit images that can potentially read lots of different formats. However most people don't need support for .sgi or .ecw files and won't have the libraries to read those formats installed. Your program is still perfectly usable without those libraries and so you should still be able to compile and run it, just without support for those formats.
- mrmonkeyman 6y ago
  I like the idea, but the reality is that it fosters extreme complexity on all kinds of axes for marginal benefit. Sure, for hobbyists it is fine but professional use.. I disagree.
- user-the-name 6y ago
  Then you end up with a program where the users can never trust it to have any given feature. They use it all the time to edit .sgi files, and then install it on a new computer, and bam, suddenly, no support for .sgi files. Or even worse, it is used as a dependency in a script, or it is a library linked by another program, but the author can never trust that any given installation has the feature he actually needs. It is a mess. Just don't do it.
  - amelius 6y ago
    Exactly. By the way another thing I've come to hate is configure or make scripts which download stuff. This is really annoying if you want to build self-contained packages. Or if the downloaded material ends up being not available, or if you're not always connected to the internet.
  - AshamedCaptain 6y ago
    The disadvantage is very mild, and the advantage huge (modularity and ability to easily go embedded). If your dependency manager cannot express "program[+feature]", it is your dependency manager's problem.
    - 6y ago
bayindirh 6y ago
> I never understood the concept of "optional" library. Consider a scientific software, let's call it x. x can solve many problems and these problems cross-cut a lot of disciplines. A researcher, user of x has a need for only subset of these features, and configures & compiles x with the features only he/she needs. This has many advantages from simpler setup to shorter build to easier verification. When you're compiling software on remote, restricted systems; these optional components makes people's life a lot easier. Also, esp. in scientific community, every library needs something lower level so, trying to compile everything in results in exponential dependency hikes. Optional components solve this very neatly.
- dagw 6y ago
  Another similar use case that is quite common is that your tool can use one of several different calculation kernels. For example there is one option that is fast but closed source, one that is open source but slower and one option that only works with Nvidia GPUs. Most people won't have all three options available, but as long as you have one of them the software works fine.
josefx 6y ago
One of the frameworks I use optionally supports a commercial library. If the library is present it enables support, if it isn't it just compiles without it. This is a nice feature since it avoids a lot of manual configuration. The downside is that support fails silently if the library is missing - since that is the expected case for most users.
jononor 6y ago
And what if your program needs a version of libpng above a certain version? And maybe below another one? That can give compile errors that are quite alot harder to grok.
jasode 6y ago
>I never understood the concept of "optional" library.[...] In case it is not installed the compiler will fail with a very clear error message. [...] and in your makefile you will link your executable with -lpng. And that is all! This works in linux, bsd and macOS. What the fucking else do you need? Interesting condescending tone there. I didn't downvote but if I can try to answer the core part of your misunderstanding: Many do _not_ want the build to fail when library png is missing. Example projects using this type of build optionality are FFmpeg and Qt. For example, ffmpeg lets you build with the optional Fraunhofer FDK AAC (libfdk_aac)[1] encoder but it is not GPL license compatible. If everyone followed your "assume libfdk_aac is already installed" advice, many people would be stuck at the "very clear error message" and not be able to have a working GPL ffmpeg. Same idea with Qt optional libraries. [1] https://trac.ffmpeg.org/wiki/Encode/AAC https://trac.ffmpeg.org/wiki/Encode/AAC
- kgwgk 6y ago
  Come on, then just edit a configuration file specifying what libraries you want to use and where they are! /s
  - matthewaveryusa 6y ago
    Ok, humor me for a second: What's wrong with that?
    - kgwgk 6y ago
      It's not "wrong". It's a choice. You can provide some code and let the users do whatever is needed to get it to compile on their system. Or you can try to automate the process with the best of intentions and create a monster. In any case, the reason why autotools exists in the first place is that people were less than thrilled with the work required to make things work by hand.
      - twic 6y ago
        Users should ask for something, and the build should build that, or fail if it can't. Randomly linking against things if they happen to be available is a terrible idea. Does any build ecosystem except C do this? I'm not sure even CMake does this.
wheels 6y ago
Large projects can take dozens of minutes up to hours to compile. It's extremely frustrating if the build system doesn't tell you in advance if it expects the compile to work. Having an error message once every 20 minutes, adding a package and restarting the build is terrible. (Also, for package systems like DEB or RPM, you can't just continue a compile that half-finished.) Now imagine you're a Linux distro and doing that for thousands of packages...
- enriquto 6y ago
  > It's extremely frustrating if the build system doesn't tell you in advance if it expects the compile to work. I have only found this behavior in three different projects that used cmake. After several minutes of beautiful compilation lines in green, it turns out that the library (that cmake was supposed to check) was not installed after all. Of course it printed a beautiful error message in red. Beautiful but non-informative, that is.
zajio1am 6y ago
> I never understood the concept of "optional" library. Either your program requires a library or it doesn't. The program may have an optional feature that requires a library. It does not make sense to force everyone to install it, if such feature is used by 1 % of users. Example might be mplayer, where there are common decoding libraries used by everyone and also plenty of obsure decoding libraries. Even better is to use dlopen() to open the optional library in runtime, to fit in distribution package management paradigm, but this requires much more work than simple option to disable dependency at compile time, and even with it it is useful to have ability do disable optional dependency at compile time to avoid requiement for header files.
zajio1am 6y ago
> Say, your program is an editor of png files and it requires libpng. Thus in your code you will have > > #include <libpng.h> In addition to what other commenters wrote (failures later during compilation instead of at the start), you also need proper include path in CFLAGS. For example, gdk-pixbuf is supposed to be included by '#include <gdk-pixbuf/gdk-pixbuf.h>'. That would assume the header file is in /usr/include/gdk-pixbuf/gdk-pixbuf.h . But distribution that i use installs it in /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf.h , likely to be able to have multiple versions of header files installed togethers. You are supposed to use 'pkg-config' tool in configure script to add proper header file locations in CFLAGS to handle this (in this case -I/usr/include/gdk-pixbuf-2). > and in your makefile you will link your executable with -lpng. The library you are usimg may depend itself. on another library, you need to add -l flags for all recursively dependent libraries to linker. As this set of recursively dependent libraries may change in the future, you are supposed to use pkg-config to find proper link flags. Note that all of this is not really dependent on configure, you can do that in a simple makefile (by just calling pkg-config directly from it). So it is more about using pkg-config instead of hardcoded paths than about using configure scripts.
- enriquto 6y ago
  > proper include path in CFLAGS This makes no sense. Preprocessor options have no place in CFLAGS, which is for compiler options. I guess you meant CPPFLAGS? Putting a preprocessor option on CFLAGS is always wrong and expected to fail. > But distribution that i use installs it in If your distribution installs headers outside of the preprocessor path (or somewhere inside CPATH or C_INCLUDE_PATH), then I'd say that this distribution is broken: it has not installed the library, just copied the files somewhere. The makefile is then, correctly, expected to fail. It's just as if you had unzipped the library on /tmp, of course you would not expect the compiler to find it!
  - pjmlp 6y ago
    This kind of opinions is why the dream of Desktop Linux will keep being a dream.