3 ms·
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 I
by badsectoracula 5y ago
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.
- ilammy 5y agoMy 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.
- jonstewart 5y agoUh could you throw that up on GitHub so I could shamelessly copy it? That sounds like a great technique.
- andoma 5y agoCheck https://github.com/edenhill/mklove https://github.com/edenhill/mklove which aims to be a drop-in replacement of autotools but with sane developer experience.