4 ms·

> If you write your own configure, people may expect to be able to [...] It's a tedious task and easy to get wrong. The author's point is to do <em>without</em

by zbuf 10y ago

> If you write your own configure, people may expect to be able to [...] It's a tedious task and easy to get wrong. The author's point is to do <em>without</em> a configure step entirely, not write your own. A standard Makefile is perfectly capable of implementing these things in a manner which is clean, reasonably portable and without the level of indirection that makes things hard to debug. My own experience is that autotools has evolved to feel less standard than the modern platforms it purports to smooth over the differences in; I seem to frequently find that I can't generate a 'configure' for a 3rd party software or libraries from Git repositories because I of the wrong autotools versions. Efforts to investigate this by unpicking the various macros etc. provided in the build have almost always been unsuccessful, leaving me building from distributed .tar.gz files. With something that feels like such a moving target after 30 years, I'm glad to see people realising the benefit of a simple Makefile that's easy to customise for the edge cases.

vbernat 10y ago
He also says later in the post you can write your own configure with a bit of bourne shell. If you expect your software to be widely distributed, a custom build script is a pain for distributions as most of them are heavily relying on ./configure && make with the appropriate arguments. Distributions also rely on the ability to override certain flags, something easy to do with autotools and quite hard with plain Makefiles (compare ./configure CFLAGS=... and make CFLAGS=..., the former don't override upstream CFLAGS). I don't object that many projects have convulated and dated autotools scripts notably because they don't age well. It's easy to accumulate a lot of crap. Most projects don't get autotools because they don't know how to use plain Makefile. They do because autotools bring much more than that.
tannhaeuser 10y ago
I wish standard (POSIX) Make would be sufficient but it frequently isn't. While some Make features from GNU and BSD Make made it into the POSIX spec (such as "include"), I frequently find myself desiring a more orthogonal facility to integrate output of external programs into Make builds. That is, by using POSIX Make's "VAR=`cmd`" syntax with backtick-quoted commands (or other shell evaluation syntax), you can define macros programmatically for incorporation into build rules as lazily evaluated text substitution variables, but you can use those only in build rules rather than in requisites or targets (where they get interpreted verbatim). A partial solution would be adopting GNU Make's eager evaluation syntax (VAR:=`...`) into POSIX. OTOH, while I'm not a big fan of autotools internals (especially libtool), being able to run "./configure && make install" on tens of thousands of F/OSS packages is something I'd hate to loose. In fact, the extreme consistency in installation procedures (including use of pkg_conf etc.) and discipline in directory layout accross so many F/OSS packages is something I very much admire, given it's an unexpected outcome of a "Bazaar" style development model.
- dTal 10y ago
  >"./configure && make install" You forgot 'make'! I'm tempted to turn this into a cheap shot about how the consistency obviously isn't worth much, but I won't.
  - dfox 10y ago
    Explicitly doing 'make' is redundant for makefiles generated by any version of automake I've ever used. Dependencies are setup correctly so that install also builds everything that it installs and isn't already uptodate (I'm not sure whether 'install' also explicitly depends on 'all')
    - derefr 10y ago
      The usual reason to separate them is that if you're installing to a prefix that needs root privileges to write to, then you'll be doing something like: ./configure && make && sudo make install If you do this instead: ./configure && sudo make install ...then the compiler toolchain gets invoked as root and all the intermediate build products end up owned by root.
      - xtreme 10y ago
        There is another reason. `make -j4 && make install' would be faster than just `make install' (multi-process vs. single-process).
        atso 10y ago
        You can do `make -j4 install`. Works as intended.
zuzun 10y ago
There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself. How do you check for headers? How do you check for functions? How do you test if qsort_r expects (*)(void*, const void*, const void*) or (*)(const void*, const void*, void*) as function pointer? If people are forced to detect that kind of stuff in Makefiles, they get the urge to match `uname` against some hard-coded platforms and that's a terrible solution.
- coldtea 10y ago
  >There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself. That's part of the argument: with standards compliant code, you don't need to do "what autotools does".
  - zuzun 10y ago
    ENOTSUP is part of the standard and I do have autotools macros checking if some function calls produce that error value on the host system.
- zbuf 10y ago
  > no way you can do what autotools does in a Makefile Well, you're responding to something that wasn't actually said; "these things" quotes specifically the list of requirements given by the previous poster -- CFLAGS etc. Your example is indeed valid, it's an ugly case and I agree that testing for the feature specifically (rather than arch, compiler) is always preferred. But let's look at the practicalities -- how many of these cases do I actually need in a codebase to tip the balance that would justify use of autoconf? In your example, a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. qsort_r is off limits for massively portable program anyway, so autoconf's ability to help is limited anyway.
  - marcosdumay 10y ago
    > a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. That's equivalent to the uname trick the GP was complaining about. That means your software won't compile in a lot of platforms. On a small scale, I don't think that's a big problem. Somebody on those platforms only has to add the correct conditions to your #ifdef forest and if he sends the update back, other people on the same platform won't even have the same problem. It's not much different from software not working on untested platforms. It starts becoming a problem when done often, or on high level (at the calling stack) code.

by zbuf 10y ago

vbernat 10y ago

He also says later in the post you can write your own configure with a bit of bourne shell. If you expect your software to be widely distributed, a custom build script is a pain for distributions as most of them are heavily relying on ./configure && make with the appropriate arguments. Distributions also rely on the ability to override certain flags, something easy to do with autotools and quite hard with plain Makefiles (compare ./configure CFLAGS=... and make CFLAGS=..., the former don't override upstream CFLAGS). I don't object that many projects have convulated and dated autotools scripts notably because they don't age well. It's easy to accumulate a lot of crap. Most projects don't get autotools because they don't know how to use plain Makefile. They do because autotools bring much more than that.

tannhaeuser 10y ago

I wish standard (POSIX) Make would be sufficient but it frequently isn't. While some Make features from GNU and BSD Make made it into the POSIX spec (such as "include"), I frequently find myself desiring a more orthogonal facility to integrate output of external programs into Make builds. That is, by using POSIX Make's "VAR=`cmd`" syntax with backtick-quoted commands (or other shell evaluation syntax), you can define macros programmatically for incorporation into build rules as lazily evaluated text substitution variables, but you can use those only in build rules rather than in requisites or targets (where they get interpreted verbatim). A partial solution would be adopting GNU Make's eager evaluation syntax (VAR:=`...`) into POSIX. OTOH, while I'm not a big fan of autotools internals (especially libtool), being able to run "./configure && make install" on tens of thousands of F/OSS packages is something I'd hate to loose. In fact, the extreme consistency in installation procedures (including use of pkg_conf etc.) and discipline in directory layout accross so many F/OSS packages is something I very much admire, given it's an unexpected outcome of a "Bazaar" style development model.

dTal 10y ago
>"./configure && make install" You forgot 'make'! I'm tempted to turn this into a cheap shot about how the consistency obviously isn't worth much, but I won't.
- dfox 10y ago
  Explicitly doing 'make' is redundant for makefiles generated by any version of automake I've ever used. Dependencies are setup correctly so that install also builds everything that it installs and isn't already uptodate (I'm not sure whether 'install' also explicitly depends on 'all')
  - derefr 10y ago
    The usual reason to separate them is that if you're installing to a prefix that needs root privileges to write to, then you'll be doing something like: ./configure && make && sudo make install If you do this instead: ./configure && sudo make install ...then the compiler toolchain gets invoked as root and all the intermediate build products end up owned by root.
    - xtreme 10y ago
      There is another reason. `make -j4 && make install' would be faster than just `make install' (multi-process vs. single-process).
      - atso 10y ago
        You can do `make -j4 install`. Works as intended.

zuzun 10y ago

There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself. How do you check for headers? How do you check for functions? How do you test if qsort_r expects (*)(void*, const void*, const void*) or (*)(const void*, const void*, void*) as function pointer? If people are forced to detect that kind of stuff in Makefiles, they get the urge to match `uname` against some hard-coded platforms and that's a terrible solution.

coldtea 10y ago
>There's no way you can do what autotools does in a Makefile without implementing half of autotools yourself. That's part of the argument: with standards compliant code, you don't need to do "what autotools does".
- zuzun 10y ago
  ENOTSUP is part of the standard and I do have autotools macros checking if some function calls produce that error value on the host system.
zbuf 10y ago
> no way you can do what autotools does in a Makefile Well, you're responding to something that wasn't actually said; "these things" quotes specifically the list of requirements given by the previous poster -- CFLAGS etc. Your example is indeed valid, it's an ugly case and I agree that testing for the feature specifically (rather than arch, compiler) is always preferred. But let's look at the practicalities -- how many of these cases do I actually need in a codebase to tip the balance that would justify use of autoconf? In your example, a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. qsort_r is off limits for massively portable program anyway, so autoconf's ability to help is limited anyway.
- marcosdumay 10y ago
  > a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. That's equivalent to the uname trick the GP was complaining about. That means your software won't compile in a lot of platforms. On a small scale, I don't think that's a big problem. Somebody on those platforms only has to add the correct conditions to your #ifdef forest and if he sends the update back, other people on the same platform won't even have the same problem. It's not much different from software not working on untested platforms. It starts becoming a problem when done often, or on high level (at the calling stack) code.