[libcxx] r342073 - Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955

[Marshall Clow via cfe-commits]

On Tue, Oct 2, 2018 at 10:33 AM Christof Douma <Christof.Douma at arm.com>
wrote:

> Hi Marshall.
>
> I think that this patch breaks backwards compatibility.  Assumes that the
> header file "version" is used by C++ projects that use a C++ standard that
> did not specify a 'version' header. Many toolchains will put search paths
> specified with -I in front of the system search path. The result is that
> the application header file is included whenever a standard header file is
> included. That is unexpected and can break builds.
>
> Do you agree this is an issue or do you consider this an issue with the
> way toolchains handle include search paths?


Christof -

I've been thinking about this the last few days.

We can ameliorate this in libc++, (See Richard's suggestion on __version)
but anything we do will be a short-term solution.
The first time someone includes another header file that #include
<version>, they're back to square one.
That header is supposed to be "the place to go" for information about your
standard library, and people are going to use it.
For example, I expect that Boost.Config will start using it soon (if it
doesn't already)

A better solution (and not just because it would require other people to do
the work) would be to have the build systems either:
* Stop using VERSION as a file name - use something like VERSION.STAMP
instead.
* Use '-iquote' instead of '-I' to manage the list of include directories.

I agree that it's annoying for people's builds to be broken when they
upgrade their development tools,
and especially when they didn't do anything "wrong".

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20181022/111dff1f/attachment.html>