<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 10:33 AM Christof Douma <<a href="mailto:Christof.Douma@arm.com">Christof.Douma@arm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marshall.<br>
<br>
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.<br>
<br>
Do you agree this is an issue or do you consider this an issue with the way toolchains handle include search paths?</blockquote><div><br></div><div>Christof -</div><div><br></div><div>I've been thinking about this the last few days.</div><div><br></div><div>We can ameliorate this in libc++, (See Richard's suggestion on __version) but anything we do will be a short-term solution.</div><div>The first time someone includes another header file that #include <version>, they're back to square one.</div><div>That header is supposed to be "the place to go" for information about your standard library, and people are going to use it.</div><div>For example, I expect that Boost.Config will start using it soon (if it doesn't already)</div><div><br></div><div>A better solution (and not just because it would require other people to do the work) would be to have the build systems either:</div><div>* Stop using VERSION as a file name - use something like VERSION.STAMP instead.</div><div>* Use '-iquote' instead of '-I' to manage the list of include directories.</div><div><br></div><div>I agree that it's annoying for people's builds to be broken when they upgrade their development tools,</div><div>and especially when they didn't do anything "wrong".</div><div><br></div><div>-- Marshall</div></div></div>