3 ms·
All good things if you want to use the autotools. And other tools too. I've been porting and compiling Unix programs since 5 years before Linux. There was a lo
by fl7305 3y ago
All good things if you want to use the autotools. And other tools too.
I've been porting and compiling Unix programs since 5 years before Linux. There was a lot of work needed to port between Unix variants, or even worse, non-Unix variants. So I can see the problem that the autotools solve.
But I never spent much time learning the details on how the autotools work. When './configure' has some problem, it is a very steep uphill battle to get any traction on the issue.
So I'd be more in the camp of looking for a different solution than autotools.
- jononor 3y agoYeah a lot of the complexity that configure scripts are supposed to solve are massively reduced now. Both because there is better harmonization between platforms, and many checks in a N year old are probably no longer relevant. So a first pass should probably be to eliminate as much checks as possible. But there will almost always be a need for a couple of build time checks/switches - should be supported by some kind of tooling.
- fl7305 3y agoI'm not very familiar with CMake, would it be viable and better to change over to that?
- jononor 3y agoCmake has a set of standardized macros to perform checks on the platform being built for. Including many specialized for typical usecases, like checking if a C header is present. And the generic CheckCompiles allows specifying a regex to match for check to be considered "failed". https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html https://cmake.org/cmake/help/latest/manual/cmake-modules.7.h... So it seems considerably better than configure scripts. Probably also better than my idea :p I don't know how easy it would be for an adversary to do something "underhanded" though, or how easy that would be to spot such.