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

[Christof Douma via cfe-commits]

Hi Marshall and others.

After this discussion and some internal discussions I agree with the idea that files without extension are treated as C++ header files and non-header files should either move out of the C++ code base or have a proper extension. The VERSION case is just the most visible case of it. The introduction of new headers that break existing projects can be handled with the use of -iquote or by using project specific names if people care about future proofing their projects. Makes me wonder if clang should make -I to mean -iquote and have an -iangle option for the language headers instead. Anyway, I’m happy to leave it at this.

Thanks for everybody’s time and thoughts on this.

Thanks,
Christof

From: Marshall Clow <mclow.lists at gmail.com>
Date: Monday, 22 October 2018 at 15:41
To: Christof Douma <Christof.Douma at arm.com>
Cc: "cfe-commits at lists.llvm.org" <cfe-commits at lists.llvm.org>, nd <nd at arm.com>, Arnaud De Grandmaison <Arnaud.DeGrandmaison at arm.com>, Jonathan Wakely <cxx at kayari.org>
Subject: Re: [libcxx] r342073 - Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955

On Tue, Oct 2, 2018 at 10:33 AM Christof Douma <Christof.Douma at arm.com<mailto: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/02ddc49a/attachment-0001.html>