Seems a bit weird that this is necessary, found this (closed) Python issuepython/cpython#70040. But if that is needed for the warning 🤷 (maybe a comment that it is just to silence a warning on some setups?)...

On which platforms/compilations are you seeing the warning?

This is on Linux (Fedora) compiling the meson branch.

That function is defined incpython/pytime.h which is included byPython.h.time.h is included bypyport.h which is included beforepytime.h inPython.h.

Perhaps in Fedora the upstream code is modified?

Looking at the Fedora sources for Python 3.10, I see the same. Here is the section ofpyport.h that includestime.h:

#ifdefTIME_WITH_SYS_TIME#include<sys/time.h>#include<time.h>#else/* !TIME_WITH_SYS_TIME */#ifdefHAVE_SYS_TIME_H#include<sys/time.h>#else/* !HAVE_SYS_TIME_H */#include<time.h>#endif/* !HAVE_SYS_TIME_H */#endif/* !TIME_WITH_SYS_TIME */

However,sys/time.h does not includebits/types/struct_timespec.h, wheretimespec is defined, in comparison totime.h, which does.

I can't find a good reference on whensys/time.h shoudl be preferred; only some comments that it may be "more portable". But since it doesn't define the struct needed, I think Python should always usetime.h, rather?

Maybe the question then is why we don't haveTIME_WITH_SYS_TIME defined; that could be the proper fix.

pyconfig-64.h already setsTIME_WITH_SYS_TIME to 1, so there should be no problem here.

Here isthe current HEAD CPython version of the code you pointed to:

/******************************************** * WRAPPER FOR <time.h> and/or <sys/time.h> * ********************************************/#ifdef HAVE_SYS_TIME_H#include <sys/time.h>#endif#include <time.h>

This was simplified from the code you pointed to in CPython PRpython/cpython#29441 without a comment, seemingly to adapt to a change in autoconf.

Edit: the change was applied to CPython3.11+ but was not backported.

Thisalso appears on CI with Python 3.11.

OK, I think I figured it out.time.h contains the following:

#if defined__USE_POSIX199309|| defined__USE_ISOC11# include<bits/types/struct_timespec.h>#endif

The following patches would make the warning go away, but I'm not sure if we're willing to jump to C11:

diff --git a/meson.build b/meson.buildindex 775d59688..3784fe7b0 100644--- a/meson.build+++ b/meson.build@@ -9,7 +9,7 @@ project(   meson_version: '>= 0.64.0',   default_options: [     'buildtype=debugoptimized',-    'c_std=c99',+    'c_std=c11',     'cpp_std=c++11',     'blas=openblas',     'lapack=openblas',

Alternatively, setting-D_XOPEN_SOURCE to greater than 600should accomplish the same (and this is indeed done inpyconfig.h, as well as the system'sfeatures.h), but somehow that's not working the way it's supposed to. This is from my localfeatures.h:

# define_XOPEN_SOURCE700# define_POSIX_C_SOURCE200809L#if defined_POSIX_C_SOURCE&& (_POSIX_C_SOURCE-0) >=199309L# define__USE_POSIX1993091#endif

While investigating, I came uponthis S/O answer that explains it all nicely.

Thanks@stefanv! Defining_XOPEN_SOURCE is preferred I think.

Jumping to C11 should be relatively safe by now, but it's hard to be sure on niche platforms. This would be less of a problem if we leftc_std undefined (but then we have to deal with lower versions otherwise, because C99 is the actual minimum), or if there was a way to express ">=C99". But that last thing isn't possible yet.

Nice digging. I wonder why setup.py doesn't run into this. Is it because setup.py and meson use differentxxx fromsysconfig.get_config_var("xxx") to set the CFLAGS?

I wonder why setup.py doesn't run into this. Is it because setup.py and meson use differentxxx fromsysconfig.get_config_var("xxx") to set the CFLAGS?

It's because there-std=c99 isn't passed for all targets withsetup.py, only for a few targets where we've had failures before. So it will show up on older platforms/compilers, but not on the ones we use in CI or locally most likely.

Do you understand why-std=c99 triggers the error? Does that also implicitly unset any of the defines necessary?

Yes, it asks for strict C99 mode, not C99 + POSIX or "whatever the compiler can do".

For future reference, looks like all this magic happens inside offeatures.h.

Here is the diff between preprocessing directives with and without-std=c11 (seeecho | gcc -std=c11 -dM -E -):

-#define linux 1-#define unix 1-#define __STDC_VERSION__ 201710L+#define __STDC_VERSION__ 201112L+#define __STRICT_ANSI__ 1

It's the__STDC_VERSION__ that affects whether or notstruct_timespec.h gets imported:

#if defined __USE_POSIX199309 || defined __USE_ISOC11# include <bits/types/struct_timespec.h>#endif

I can confirm that setting_ISOC11_SOURCE makes the warning go away!

@rgommers I've pushed a commit to your branch; not sure if a global flag is the right solution or not, so feel free to drop/replace the patch.

@rgommers I've pushed a commit to your branch; not sure if a global flag is the right solution or not, so feel free to drop/replace the patch.

I had a look, this silences the warning but isn't quite the right thing to do. The problem was that some files included standard library headers before they includedPython.h. That is always wrong, as explained in theNote box underhttps://docs.python.org/3/extending/extending.html#a-simple-example. I fixed it by reordering headers in the Meson PR.

I'll also note that you always want to useadd_project_arguments instead ofadd_global_arguments - the difference is scoping, the global version affects Meson subprojects as well (we don't have any yet, but that may change - I was just playing with one this morning).

I suggest we close this PR.

Closed by82fd2b8

For completeness, note that compilation now defaults to c99 and c++14.