News for hackers. Stuff that matters.
Re:Strengths, weaknesses, opportunities, and threats facing ... by badsectoracula on Monday May 02, 2022 @05:19AM (#31232834)
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.

Re:Strengths, weaknesses, opportunities, and threats facing ... by ilammy on Monday May 02, 2022 @06:13AM (#31233221)
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.

Re:Strengths, weaknesses, opportunities, and threats facing ... by jonstewart on Tuesday May 03, 2022 @12:20AM (#31244574)
Uh could you throw that up on GitHub so I could shamelessly copy it? That sounds like a great technique.
Re:Strengths, weaknesses, opportunities, and threats facing ... by andoma on Monday May 02, 2022 @07:58AM (#31233957)
Check https://github.com/edenhill/mklove which aims to be a drop-in replacement of autotools but with sane developer experience.