Re: Request to rename version.h

[Ethan A M. <me...@uw...>]

On Sunday, November 3, 2019 8:15:15 PM PST Marcus Calhoun-Lopez wrote:
> Greetings.
> 
> My name is Marcus Calhoun-Lopez, and Mojca was kind enough to include me in this discussion.
> I originally raised this issue.
> 
> The source of the error is as follows:
> *) In the file gnuplot-5.2.7/src/Makefile.in, there is the line of code
>        DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
> *) The -I switch means that Clang (and GCC) search $(top_builddir) before the default include directions.
> *) Clang (and GCC) have a file called version in the default included directories (likely to be part of the C++20 standard).
> *) On case-insensitive file systems (like the the default macOS file system), the files version and VERSION are the same.
> *) In $(top_builddir), there is a file called VERSION.
> *) gnuplot indirectly has an #include <version>.
> *) Instead of finding version in the default include directories, it finds the file VERSION in $(top_builddir).
> *) This causes an error.
> 
> If -I$(top_builddir) is replaced with -idirafter$(top_builddir), the problem goes away.
> 
> I am sorry if this is a little long winded.
> Please let me know if I can clarify.
> I can create a simple test program if that would help.

Thank you for the explanation Marcus.

(1)
Are you saying that the issue is a pending (c++20) change to clang's
implementation-specific definition of the forms:
	#include <foo>
vs	#include "foo"     ????

That would be weird, as it introduces a possible collision any time a local
directory contains a file that has the same name as a system file.

(2)
I cannot reproduce the problem on linux using either gcc 9.2.1 or clang 9.0.0.
In the case of gcc, I tried both with and without  compiler option -std=c2x.
Furthermore neither the gcc nor the clang installation brought with it a
system file named "version".   So there is more to it than just the compiler version.

Mojca's error message refers to 
>    /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
>   ../version:1:1: error: expected unqualified-id
Does this indicate that the problem is an include statement in a file 
"cstddef" provided by a OSX-specific llvm?

The cstddef file provided by gcc-9.2.1 does not contain any such statement. 
I do not find a separate cstddef file associated with clang.

(3)
Is it certain that this whole issue would go away if we were to delete  the
"VERSION" file altogether from the gnuplot source?
It really seems to me that Mojca has encountered a deeper problem with
the compiler toolchain.

(4)
The attached patch removes VERSION from current git head for the
development branch.  It works on linux in my initial tests but I will hold off
commiting it pending further confirmation.

	Ethan


> 
> Thank you,
> Marcus
> 
> > On Nov 3, 2019, at 8:45 PM, Ethan Merritt (UW) <me...@uw...> wrote:
> > 
> > On Sunday, 03 November 2019 18:56:09 Ethan Merritt wrote:
> > > > /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> > > > ../version:1:1: error: expected unqualified-id
> > > > 5.2
> > > > ^
> > > > 
> > > > > And frankly, I cannot believe any tool vendor nor standardization body
> > > > > would be so daft as to assume that <version.h> is a suitable name for a
> > > > > new standard header.  There must be roughly several million pre-existing
> > > > > user header files by that name out there that this would trample on.
> > > > 
> > > > Well ... the fact is that the build breaks when using the latest clang
> > > > compiler. And on old OS versions this is now the default behaviour in
> > > > MacPorts, so gnuplot build is currently broken for many of our users.
> > >  
> > > I can build from current git head using clang 9.0.0 without any problem.
> > > My wxgtk version is 3.1
> > >  
> > > On my system cstddef.h does not refer to VERSION anywhere.
> > > However that file came from gcc, not from llvm.
> > > I don't know where that gets us in debugging your problem,
> > > but it seems not to be a problem with clang per se.
> > >  
> > > Note that the syntax
> > >    #include <FILENAME>
> > > should only look in "a standard list of system directories".
> > > I do not know where that standard list is defined, but in any
> > > case it should not include the current working directory.
> > > So a local file named VERSION would not conflict.
> > >  
> > > 	Ethan
> > >  
> > >  
> > > > 
> > > > It hardly makes sense to start pointing fingers about who was supposed
> > > > to figure out that VERSION would be loaded first when one of the
> > > > compiler's own files says "#include <version>" ...
> > > > 
> > > > Mojca


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742