4 ms·

In the systems I have seen: * Because the rules are generated. Building a subpart sometimes means invoking a generated rule. * Because make is used for ot

by grive 6y ago

In the systems I have seen: * Because the rules are generated. Building a subpart sometimes means invoking a generated rule. * Because make is used for other things: building binaries, libraries, examples, test suite, documentation -- then executing them, preparing a test environment, installing them, generating distribution packages, etc. * Because the system is a framework, and each rule relates to one of many plugins (Buildroot for example). * Because the system is just very large and complex (linux). Now to go back to automake. It is still very useful to have automated checks of compliance -- either about some extended warnings supported only by some compilers and not others (clang vs GCC), allowing extensions, static analysis, coverage, etc. That being said, automake is terrible. The two passes to generate the actual build systems means most people are actually reading generated makefile and debugging that. As was said by GP, it is also sub-optimal regarding use of make. Frankly, it is just much simpler to directly work with makefiles, or change build tool altogether (meson + ninja is nice). Autotools has always been a nightmare to work with in my experience. Keeping with make, I much prefer musl way for example, where a POSIX shell script examines the dependencies and configures a single makefile giving the project state, then the actual makefiles will consume it to operate properly.

cat199 6y ago
> Frankly, it is just much simpler to directly work with makefiles agree. pmake (colloquially bsd make though it arrived late in the CSRG era) allows for the concept of a 'makefile library' that handles common things (e.g. '.include <bsd.prog.mk>' to build a program if the project directory is laid out appropriately) which I think would have been a much better approach for autotools instead of generating makefiles in multiple stages. Unfortunately the autotools approach is many peoples 1st exposure to anything make-like so they are left with a bad impression of makefile complexity. IMHO pmake also has a nicer and more flexible syntax extension over posix vs gnumake (e.g. can define a dynamic target in a for loop). Unfortunately pmake is not very well known outside of the BSD community.
sigjuice 6y ago
Reading and debugging the generated makefile should not be the norm IMHO. For the same reason that is isn't usually required to read and debug generated assembly (from C), Java/Python bytecode etc.
- jschwartzi 6y ago
  Sure, except that the language used to generate the makefile is substantially harder to read in a lot of cases. And it doesn't tell you important things such as how libtool paths are configured or what paths are included in the gcc commands. These aren't that important unless you're cross-compiling for a system that doesn't have the same libc, libgcc, or library set and for which you need to set a "sysroot." Different projects have different ways of doing this, and sometimes a project will use something that sets sysroot appropriately for libtool but then doesn't generate the --sysroot command for gcc. For historical reasons Cross Compilation against a different root filesystem for a different target architecture is somewhat of a second-class citizen in most automake/autotools build systems and you really do have to read the makefile output to figure out how they've configured their particular instance.

by grive 6y ago

cat199 6y ago

> Frankly, it is just much simpler to directly work with makefiles agree. pmake (colloquially bsd make though it arrived late in the CSRG era) allows for the concept of a 'makefile library' that handles common things (e.g. '.include <bsd.prog.mk>' to build a program if the project directory is laid out appropriately) which I think would have been a much better approach for autotools instead of generating makefiles in multiple stages. Unfortunately the autotools approach is many peoples 1st exposure to anything make-like so they are left with a bad impression of makefile complexity. IMHO pmake also has a nicer and more flexible syntax extension over posix vs gnumake (e.g. can define a dynamic target in a for loop). Unfortunately pmake is not very well known outside of the BSD community.

sigjuice 6y ago

Reading and debugging the generated makefile should not be the norm IMHO. For the same reason that is isn't usually required to read and debug generated assembly (from C), Java/Python bytecode etc.

jschwartzi 6y ago
Sure, except that the language used to generate the makefile is substantially harder to read in a lot of cases. And it doesn't tell you important things such as how libtool paths are configured or what paths are included in the gcc commands. These aren't that important unless you're cross-compiling for a system that doesn't have the same libc, libgcc, or library set and for which you need to set a "sysroot." Different projects have different ways of doing this, and sometimes a project will use something that sets sysroot appropriately for libtool but then doesn't generate the --sysroot command for gcc. For historical reasons Cross Compilation against a different root filesystem for a different target architecture is somewhat of a second-class citizen in most automake/autotools build systems and you really do have to read the makefile output to figure out how they've configured their particular instance.