3 ms·

> ... but I'm not sure how much I should be blaming autotools versus the projects that use autotools. Definitely the latter. Few projects treat `configure.ac`

> ... but I'm not sure how much I should be blaming autotools versus the projects that use autotools. Definitely the latter. Few projects treat `configure.ac` and its macros as serious as programming should be. They produce spaghetti code, duplicate code, patched code, slow code, unmaintainable code and they leave it there for decades only add code to make it worse, without ever feel the embarrassment to fix it. Of course blame the coder before blame the language.

yjftsjthsd-h 6y ago
I dunno, if a majority of projects using X come out bad, eventually it is a fault in X, not just bad users.
- kelnos 6y ago
  Not really. As an example, the configure script will often output a "config.h" header that will have a bunch of preprocessor macros that the developer can use to make decisions about what platform features are supported. So you might have HAVE_FOO and HAVE_BAR in config.h. But if the developer doesn't do something like: #ifdef HAVE_FOO int ret = foo(); #elif HAVE_BAR int ret = bar(); #else int ret = do_some_fallback(); #endif ... then that's on the developer for just working on a system that has foo() and doesn't consider other systems that only have bar(), or have neither. Of course, that assumes they even put the tests for foo() and bar() in configure.ac in the first place! I would still use autotools for a C project even if I was only targeting linux/x86_64, just so I could write a simple declarative Makefile.am file that lists sources and defines target outputs, and have autoconf/automake figure out everything else, and put it behind a standard interface (that is, one that respects prefix, destdir, etc.). Also being able to easily write tests for dependencies and get the appropriate cflags and ldflags makes life easier.
  - pjmlp 6y ago
    Yes really, if everyone does it wrong, it means something is lacking to put those peoples in the right track from the start.
- dapids 6y ago
  Can you supply said statistic?
TylerE 6y ago
So you're saying it's the PHP of build tools? ...that kinda works, actually.
sigjuice 6y ago
Are there any good examples of configure.ac macros that would be useful to study?

yjftsjthsd-h 6y ago

I dunno, if a majority of projects using X come out bad, eventually it is a fault in X, not just bad users.

kelnos 6y ago
Not really. As an example, the configure script will often output a "config.h" header that will have a bunch of preprocessor macros that the developer can use to make decisions about what platform features are supported. So you might have HAVE_FOO and HAVE_BAR in config.h. But if the developer doesn't do something like: #ifdef HAVE_FOO int ret = foo(); #elif HAVE_BAR int ret = bar(); #else int ret = do_some_fallback(); #endif ... then that's on the developer for just working on a system that has foo() and doesn't consider other systems that only have bar(), or have neither. Of course, that assumes they even put the tests for foo() and bar() in configure.ac in the first place! I would still use autotools for a C project even if I was only targeting linux/x86_64, just so I could write a simple declarative Makefile.am file that lists sources and defines target outputs, and have autoconf/automake figure out everything else, and put it behind a standard interface (that is, one that respects prefix, destdir, etc.). Also being able to easily write tests for dependencies and get the appropriate cflags and ldflags makes life easier.
- pjmlp 6y ago
  Yes really, if everyone does it wrong, it means something is lacking to put those peoples in the right track from the start.
dapids 6y ago
Can you supply said statistic?

TylerE 6y ago

So you're saying it's the PHP of build tools? ...that kinda works, actually.

sigjuice 6y ago

Are there any good examples of configure.ac macros that would be useful to study?