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.li...@gmail.com>
Date: Monday, 22 October 2018 at 15:41
To: Christof Douma <christof.do...@arm.com>
Cc: "cfe-commits@lists.llvm.org" <cfe-commits@lists.llvm.org>, nd 
<n...@arm.com>, Arnaud De Grandmaison <arnaud.degrandmai...@arm.com>, Jonathan 
Wakely <c...@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.do...@arm.com<mailto:christof.do...@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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to