My build of the 3.5 head fails in timemodule.c which results in an interpreter that can run but can't "import time".

Details:
changeset 96851:bb9fc884a838
on Fedora Linux x86_64 

Output:
/home/tim/build/cpython/Modules/timemodule.c: In function ‘time_strftime’:
/home/tim/build/cpython/Modules/timemodule.c:656:9: error: unknown type name ‘_Py_BEGIN_SUPPRESS_IPH’
         _Py_BEGIN_SUPPRESS_IPH
         ^
/home/tim/build/cpython/Modules/timemodule.c:656:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
/home/tim/build/cpython/Modules/timemodule.c:658:9: error: ‘_Py_END_SUPPRESS_IPH’ undeclared (first use in this function)
         _Py_END_SUPPRESS_IPH
         ^
/home/tim/build/cpython/Modules/timemodule.c:658:9: note: each undeclared identifier is reported only once for each function it appears in
/home/tim/build/cpython/Modules/timemodule.c:662:9: error: expected ‘;’ before ‘if’
         if (buflen > 0 || i >= 256 * fmtlen) {
         ^
/home/tim/build/cpython/Modules/timemodule.c:657:9: warning: unused variable ‘buflen’ [-Wunused-variable]
         buflen = format_time(outbuf, i, fmt, &buf);
         ^
/home/tim/build/cpython/Modules/timemodule.c:561:20: warning: unused variable ‘buflen’ [-Wunused-variable]
     size_t fmtlen, buflen;
                    ^
/home/tim/build/cpython/Modules/timemodule.c:561:12: warning: variable ‘fmtlen’ set but not used [-Wunused-but-set-variable]
     size_t fmtlen, buflen;
            ^
cc1: some warnings being treated as errors

Failed to build these modules:
time

This patch works for me on Linux but it seems clearly wrong for windows.

The problem is that using it on windows introduces a dependency and I don't have a windows machine to check if this is ok.  To me it seems that the time module must have been built as part of the core somehow in the past. 

diff -r 5adf995d443f Modules/timemodule.c
--- a/Modules/timemodule.c	Mon Jul 06 14:03:01 2015 +0300
+++ b/Modules/timemodule.c	Mon Jul 06 14:15:52 2015 +0100
@@ -30,6 +30,13 @@
 #endif /* MS_WINDOWS */
 #endif /* !__WATCOMC__ || __QNX__ */
 
+#define Py_BUILD_CORE 
+#include "pyport.h"
+
+#define _Py_BEGIN_SUPPRESS_IPH
+#define _Py_END_SUPPRESS_IPH
+
+
 /* Forward declarations */
 static int pysleep(_PyTime_t);
 static PyObject* floattime(_Py_clock_info_t *info);

It works for us.  I've added Steve Dower to nosy, who I believe added that code.  IIUC it should only come into play on Windows.

Are you using a stock checkout, or have you applied local modifications?  The changeset id you reference doesn't have IPH in it.

Last time this came up the solution was either "hg purge" or "make distclean", I don't remember which worked.

timemodule.c should already be built with Py_BUILD_CORE set in CFLAGS, but apparently it's possible for that setting to disappear from one of the generated build files.

I'm so sorry. I apologise for mucking up and giving you the wrong changeset :-(

my hg summary output is as follows:

parent: 96850:5adf995d443f 
 Issue #18684: Fixed reading out of the buffer in the re module.
branch: 3.5
commit: 2 unknown (clean)
update: (current)
mq:     1 unapplied

I have no modifications. 

The macros only have meaningful definitions on windows and they come from ./Include/pyport.h.

I could just include this but they are protected by Py_BUILD_CORE so I'm not clear what's really going on and ... hence I leave it to others.

Ok so I see the compiler is including pyport.h (using strace) so that means that it can only be a case of  Py_BUILD_CORE not being in CFLAGS for timemodule.o.

I suppose that this is a configure problem.  I'll try to work out how/why.

Why is it important to hide these 2 macroses behind Py_BUILD_CORE?

Certain tools for embedding python may try to compile modules independently. I realize that it's not a problem of Python to take care of that, but in that particular case if hiding these 2 macroses behind Py_BUILD_CORE is not required, it may help to retain compatibility with such tools.

setup.py gets C flags from Makefile using the sysconfig module. You must have -DBUILD_CORE in Makefile. When I compiled Python using "./configure; make" the time module is build.

How do you compile Python?

"#define _Py_BEGIN_SUPPRESS_IPH" is already declared in pyport.h which is included by Python.h, and timemodule.c includes Python.h.

If they are compiled independently, they should have Py_BUILD_CORE set. 

That flag is meant for the headers, which serve dual purposes, not the module itself. *Any* C file that is part of core should expect that option to be set for when it includes its headers.

All that said, it seems that _datetimemodule.c forces Py_BUILD_CORE on to get access to some extra definitions, which presumably means that somebody at some point wanted to compile it into an extension module. I don't see the use case here though - is there something about its public API that is not stable?

I ran into an error like this and perhaps I have a clue was why some people run into it.  Dynamic modules built from Modules/Setup will need to have  -DPy_BUILD_CORE defined within the Setup file in the case they need to use the _Py_BEGIN_SUPPRESS_IPH macro.

The Setup file is generated on figure 'configure' but it is not removed if you run "make clean".  So, if it gets generated without the Py_BUILD_CORE flags in it, you will get this mysterious build error.

Perhaps Modules/makesetup should be intelligent and add the Py_BUILD_CORE flags as needed.  One idea is to check the path of the source code (e.g. timemodule.c) and if the source is within the code interpreter folder,  add the BUILD_CORE flag.

Not sure about other platform build systems.  It looks like PCbuild does something different as it doesn't use makesetup.