<div dir="ltr">Hi,<div><br></div><div>glibc's headers have _FOO_SOURCE configuration macros. These would naturally map to config_macros in a glibc module, *except* that glibc does this sort of thing:</div><div><br></div>
<div>// foo.h</div><div>#ifdef _FOO_SOURCE</div><div>#undef _BAR_SOURCE</div><div>#define _BAR_SOURCE 1</div><div>#endif</div><div><br></div><div>If we then include a modularized foo.h:</div><div><br></div><div>#include <foo.h></div>
<div><br></div><div>we get an immediate problem: when the preprocessor sees the include, it imports the version of the module with _BAR_SOURCE undefined, but when the parser sees the corresponding import, it thinks we're trying to import a different version of the module, because _BAR_SOURCE is now defined.</div>
<div><br></div><div>We could fix this by suppressing the warning if the macro definition comes from the same module that we're importing (or possibly any module which depends on that module). Is there a better way? Alternatively, we could deem that headers that use the same macro name as both input and output are not compatible with modules, and should be rewritten to not do that?</div>
</div>