5 ms·

This will end up including wrong headers if they happen to be erroneously present on the machine. It basically assumes that if xyz.h is present, then it must be

by eps 7y ago

This will end up including wrong headers if they happen to be erroneously present on the machine. It basically assumes that if xyz.h is present, then it must be the right header for the job. The standard approach is more robust and predictable - if we are building for X, then xyz.h must be present. It's a stronger invariant.

ComputerGuru 7y ago
> The standard approach is more robust and predictable - if we are building for X, then xyz.h must be present. It's a stronger invariant. I'm not sure if you presently maintain any popular cross-platform packages (e.g. source code + build scripts) but that hasn't been the case for a long time. With all the different fringe distributions, bastardized kernels, mix of packages installed via the preferred system package manager vs 3rd party package managers like npm, pip, and homebrew, newer versions of libraries built and installed by hand from a tarball or git checkout, etc. all modern build scripts have switched to feature detection rather than (exclusively) platform detection (which I still favor, when I can get away with it). autoconf, cmake, meson, etc. all recommend testing the toolchain for a feature (e.g. build a one-liner that tries to call a system API linking first against x, and if that fails, then y, then z) and go with whatever succeeds first (in the order suggested by the developer) leading to horribly complicated messes with infinite permutations.. but generally significantly less user issues when attempting to build a package or library. However, I do feel that I may have misunderstood you and this is the approach you are suggesting?
- compsciphd 7y ago
  autoconf et all, don't they test that the feature/api works as expected not just that something can compile if the header is included but not actually used?

5 ms·

This will end up including wrong headers if they happen to be erroneously present on the machine. It basically assumes that if xyz.h is present, then it must be

by eps 7y ago

ComputerGuru 7y ago
> The standard approach is more robust and predictable - if we are building for X, then xyz.h must be present. It's a stronger invariant. I'm not sure if you presently maintain any popular cross-platform packages (e.g. source code + build scripts) but that hasn't been the case for a long time. With all the different fringe distributions, bastardized kernels, mix of packages installed via the preferred system package manager vs 3rd party package managers like npm, pip, and homebrew, newer versions of libraries built and installed by hand from a tarball or git checkout, etc. all modern build scripts have switched to feature detection rather than (exclusively) platform detection (which I still favor, when I can get away with it). autoconf, cmake, meson, etc. all recommend testing the toolchain for a feature (e.g. build a one-liner that tries to call a system API linking first against x, and if that fails, then y, then z) and go with whatever succeeds first (in the order suggested by the developer) leading to horribly complicated messes with infinite permutations.. but generally significantly less user issues when attempting to build a package or library. However, I do feel that I may have misunderstood you and this is the approach you are suggesting?
- compsciphd 7y ago
  autoconf et all, don't they test that the feature/api works as expected not just that something can compile if the header is included but not actually used?