Meson: cc.has_header: provide a way to check for the usability of a header too

[whs]

Clang ships with intrin.h that will only run #includenext on non-Windows platform.

This cause compiler.has_header('intrin.h') false positive, as it will return true but all compilation using that header will fail.

Autoconf's AC_CHECK_HEADER use compilation to test instead of just preprocessor. I'd suggest that meson should change its behavior to be like that as well.

[nirbheek]

This is on purpose. has_header() is not the same as CHECK_HEADER() as evinced by the naming. But perhaps we could add a kwarg to cc.has_header() which forces Meson to try to use the header instead of just checking for its existence. Something like use : true.

The difference is that checking for a header's existence is a preprocessor check while checking for its usability is a compile, and the latter is much slower than the former.

[jpakkane]

@whs is this still needed or did you manage to make it work without it? The referred issue seems to be closed without further comments.

[whs]

I was trying to port libsodium to meson, but upstream rejected the patch (https://github.com/jedisct1/libsodium/pull/584) and I stopped working on it. IIRC, I used compiler detection to workaround.

[nirbheek]

@whs two things: (1) Are you still planning on submitting it as a wrap project? (2) Maybe instead of switching to meson, since upstream project is considered "done", adding meson as a parallel build system would've been more palatable.

[whs]

After trying to maintain it for a while it seemed to be too much of a work
(especially after upstream made some big change) so I'm no longer working
on it.

On Fri, Feb 9, 2018 at 8:53 PM, Nirbheek Chauhan [e-mail]
wrote:

@whs https://github.com/whs two things: (1) Are you still planning on
submitting it as a wrap project? (2) Maybe instead of switching to meson,
since upstream project is considered "done", adding meson as a parallel
build system would've been more palatable.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mesonbuild/meson/issues/2246#issuecomment-364439456,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVFi1BSwRCF2mOQ42B9R2_OvbuqqjNtks5tTE32gaJpZM4PBDB6
.

[nirbheek]

Funny that they would say that that version of libsodium is "done" and then make a huge change. I don't understand it. Anyway. :)

[dcbaker]

Autotools switched from a pre-processor check to a compile check because the mere existence of a header is never useful. I've run into this now, and I can't imagine a situation where the mere presence of a header would be sufficient for anything, not being able to use it is the same as not having it.

Anyway, #2278 looks sufficient to solve this for me, although I really think that we should compile check headers not just preprocess them.

[nirbheek]

because the mere existence of a header is never useful

I am not so sure about this. Sometimes you need to include headers in a specific order for them to be usable; I have experienced this with SDKs and Windows APIs. One option is to add those headers to the prefix:, but then you don't know which one wasn't found.

Generally, checking the existence of a header is sufficient (if it isn't usable, your toolchain is broken and a compile-time error gives more information in that case), and the speed-ups of doing this vs compiling were quite significant the last time I measured; particularly for C++ headers.

Someone also recently requested the ability to check that a header is usable with a specific list of defines from a configuration object. Perhaps we need a new function cc.check_header() that does this.

[dcbaker]

I don't know, the fact is every modern system has a sys/sysctl.h, but that none of them work for building x32 is a pretty big problem, cc.had_header will return true in every case, and the build will break in every case. You can't know what's in that header or whether it will work until you actually try to compile with it.

[nirbheek]

I agree, and I'm guessing you need to pass some configuration data (defines) to the header to figure out if sysctl.h is usable? has_header, as the name suggests, is for checking if the system "has the header", whereas "check this header" is usable with the given configuration seems better.

[nirbheek]

@dcbaker also you indicated on IRC that you were in favour of check_header, have you changed your mind?

[dcbaker]

no, adding a check_header is fine. My argument is more that in the autotools world the changed AC_CHECK_HEADER to actually compile because of the reasons I mentioned, and I forsee most good sized projects never using has_header because they need to know that the header works, not just exists.

[xclaesse]

This is hitting glib on freebsd it seems: https://gitlab.gnome.org/lantw/glib/commit/71b67621fb59985a8543ff92fb904c9e35d2c4b0#note_226110

As far as I understand the only downside of doing a compile instead of only preprocess is speed, which could be mitigated by issue #3635.

[nirbheek]

As far as I understand the only downside of doing a compile instead of only preprocess is speed, which could be mitigated by issue #3635.

1. Sometimes you need to include headers in a specific order for them to be usable; I have experienced this with SDKs and Windows APIs. One option is to add those headers to the prefix:, but then you don't know which one wasn't found. (I already noted this above)

2. Changing the behaviour will break existing compiler checks, and people will probably show up asking us to implement exists_header() to check for existence of a header.

3. check_header() would be more explicit about what it's doing anyway

[nirbheek]

https://github.com/mesonbuild/meson/pull/3643 implements cc.check_header().