3 ms·

> there are plenty of legitimate reasons that program could fail to compile It's worse than that, these small C files are required to fail unless the target bu

by fl7305 3y ago

> there are plenty of legitimate reasons that program could fail to compile It's worse than that, these small C files are required to fail unless the target build environment meets some specific requirements.

jononor 3y ago
It could be required to declare which error should happen, and at what line it should trigger. And the C program should still be syntactically valid and pass linting. One could create a tool which would have a folder of .c files to check with such declarations. And output similar things to as the configure script. Configure scrips tend to be a very slow part of projects, so a new tool that would support parallel compile/run of these checks would also have a considerable speedup. In addition to being more reviewable, verifiable and less error prone.
- 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 ago
    Yeah 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 ago
      I'm not very familiar with CMake, would it be viable and better to change over to that?
      - jononor 3y ago
        Cmake 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.

by fl7305 3y ago

jononor 3y ago

It could be required to declare which error should happen, and at what line it should trigger. And the C program should still be syntactically valid and pass linting. One could create a tool which would have a folder of .c files to check with such declarations. And output similar things to as the configure script. Configure scrips tend to be a very slow part of projects, so a new tool that would support parallel compile/run of these checks would also have a considerable speedup. In addition to being more reviewable, verifiable and less error prone.

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 ago
  Yeah 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 ago
    I'm not very familiar with CMake, would it be viable and better to change over to that?
    - jononor 3y ago
      Cmake 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.