Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: meson build #120
base: master
Are you sure you want to change the base?
WIP: meson build #120
Changes from 9 commits
63e93f5
fc52493
72f696e
8f0731e
7056bbc
d823821
3f29010
070a65d
132cde1
fc9655e
0ffc20d
aca1aa2
ae73fa4
0f2859d
96e2d96
f51a11f
be2a23a
8a7b9b1
a83a638
859f821
fb6b458
24ad34e
efcb02e
d45e486
7105a71
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since Meson 1.3.0 it's possible to have a list. For example,
c_std=gnu99,c11,c99
would prefergnu99
but then tryc11
beforec99
. I don't know if MSVC counts as C99 as it officially supports only C11, I think, perhaps due to C99 having a few mandatory features that are optional in C11.GNU extensions are used when they are available, thus
gnu99
can make sense.gnu99
vs.c99
also affect the predefined macros. On my system with GCC 13.2.1,-std=c99
defines__STRICT_ANSI__
while-std=gnu99
doesn't. It can then affect the behavior of system headers.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that some project leaders do not like to use the latest version of meson. If there is no problem for you to use meson >= 1.3, then ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually don't know right now which Meson (or muon) version is OK to require. I just get an impression that a single value doesn't work everywhere (if MSVC needs C11 mode). I haven't checked in detail how the
c_std
option in Meson exactly works.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/mesonbuild/meson/blob/master/mesonbuild/compilers/c.py#L453-L485
For MSVC, meson ignores c99 and passes /std:XXX when the mode is c11 or c17. The difference is really about whether you want to opt into GNU extensions (which MSVC obviously doesn't support). Doing that might require bumping the minimum meson requirement, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vaguely remember that, a very long time ago, using
gnu99
was better in practice when the intention was to use non-standard extensions (language or library) when they are available.If
gnu99
doesn't put MSVC into C11/C17 mode then MSVC needs some otherc_std
option. MSVC is a special case in so many ways that handling it specially here could be OK too, assuming it's easy to do.Using
gnu11
with GCC and Clang and strict C11 with compilers that don't support GNU extensions could be OK too. But if compiler doesn't support C11 then it should fallback to C99 if that is supported.The list method that requires Meson >= 1.3.0 would make all this trivially easy. muon says it's currently at meson compat version 1.1.
So, oh well, maybe try
gnu11
for now if that helps getting MSVC to C11 mode. This is a small detail in the big picture and can be worried more a little later.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what I did for muon with cl.exe compiler: I just pass the required standard. So, no problem with c11. (there will be a message from the compiler if the standard is not correct)
I maybe should pass the standard if it is only c11 or c17 like meson. I'll ask the author
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Meson docs give an impression that
c_std=gnu11
would fallback to C11 with MSVC but this might become deprecated and eventually an error. So one would need to list the possible standards.I think requiring new enough Meson and using
c_std=gnu99,c11,c99
orc_std=gnu11,gnu99,c11,c99
is fine for now. It might not be muon compatible right now but I would expect this kind of feature to get implemented at some point in muon too. Very probably the first versions of Meson support won't be as portable as the Autotools build is and it doesn't need to be. Progress happens one step at a time.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eli-schwartz: Elsewhere there is
gnu_symbol_visibility: 'hidden'
. Is it possible to use the result of that here somehow? I remember that on some platforms the attributes are accepted but produce compiler warnings as they aren't truly supported. I don't know if that is a case on any modern platform though (Cygwin was like that many years ago but I haven't tested in years).Gnulib's visibility.m4 checks that both attribute and compiler option are supported using
-Werror
to enable visibility support. Meson's documentation doesn't tell if compiler.has_function_attribute() accepts the attribute if using it produces warnings but compiling still succeeds.It's also a bit unfortunate if visibility support requires an option in both
library
and a separate check for the attribute support. Perhaps thegnu_symbol_visibility
option could insert preprocessor macros likeMESON_GNU_SYMBOL_VISIBILITY_HIDDEN __attribute__((__visibility("hidden")))
which the C/C++ code could use. I'm not sure what is the best way as perhaps this idea has downsides. And modern compilers have__has_attribute
anyway.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meson internally handles -Werror for exactly that reason:
.https://github.com/mesonbuild/meson/blob/7d28ff29396f9d7043204de8ddc52226b9903811/mesonbuild/compilers/mixins/clike.py#L1309-L1324
Most projects I have seen, actually check for
__GNUC__
instead of using visibility.m4 even with autotools. This is kind of necessary anyway since you need preprocessor logic to figure out whether Microsoft dllexport/dllimport is viable, and visibility.m4 is ultimately not all that helpful overall.Certain versions of... SunPro, if I recall correctly, are the only commonly known compiler that handles visibility but isn't either
__GNUC__
orMSC_VER
, and they use a third syntax instead?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Documenting it could be nice to give more confidence. Or perhaps it's that coming from other build systems one is constantly suspecting that corner cases aren't handled well enough, sorry.
liblzma checks in this order in the C code:
#if defined(_WIN32) || defined(__CYGWIN__)
then use__declspec(dllexport)
.#if HAVE_VISIBILITY
to use GNU C attributes. Checking for__GNUC__
wouldn't work as it can be defined on platforms that don't support the visibility attributes; one has to know if the attribute is actually supported.Otherwise assume no visibility support.
My note in b0d1422 says that SunPro (or whatever its name is this year) supports the GNU C attribute since 2007. At least modern releases support the
-fvisibility
option too. I didn't research when the command line option was added (it would make sense to add it when the attribute was but I don't know if that happened). The original option is-xldscope
but I guess there's no point to add support for it when-fvisibility
works too.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This
results in a warning with GCC 14.1.1 on x86-64 GNU/Linux:
But
cc.has_function_attribute('dllexport')
is still true. So-Werror
isn't used or Meson shortcircuits the attribute check somehow. Thus I fear it might do the same with the visibility attribute as well.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, sorry, I'm wrong. I just fell into the exact trap of
#undef
vs.#define
being too easy to mix in config.h. So the previous message is noise. Sorry.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is incorrect usage.
dependency('threads')
will always "find" a thread dependency.dependency('threads')
isn't designed to check for pthreads. It just allows you to use whatever threading API is available with the selected toolchain, so you should also use it on theif sys_windows
branch.pthreads have to be detected separately, like with
cc.check_header('pthread.h')
.CC: @eli-schwartz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At glance this sounds odd. XZ Utils can use pthreads and Windows threads. C11 threads are available on some platforms too but XZ Utils doesn't support those for now (they don't seem to add any practical value for now).
MinGW-w64 supports pthreads and Windows threads, the latter being preferred. Very recent MSVC supports C11 threads in addition to Windows threads.
When using MinGW-w64 and Windows threads, one specifically wants to ensure that the pthreads flags are not used. Thus the Autotools and CMake builds don't add any threading related options to the build when using Windows threads.
Autotools build assumes that pthreads is available on non-Windows, thus the build fails, for example, on MINIX 3 where pthreads isn't available. One has to manually use
--disable-threads
. Perhaps I should fix it to show an error atconfigure
time with a message that suggest--disable-threads
. This would match what CMakeLists.txt already does. I don't want to it to silently disable threading support.