gnuplot-beta

Request to rename version.h

[Mojca M. <moj...@gm...>]

Dear developers,

I would like to request renaming the file version.h (and potentially
version.c) to something else, for example gnuplot_version.h.

The problem is that C++20 introduced a standard header version.h:
    https://en.cppreference.com/w/cpp/header/version
which is now causing issues when using a C++20-compliant compiler for gnuplot.

We need to patch gnuplot we ship inside a package manager as soon as
possible, but ideally I would like to use the same patch as upstream.

Thank you very much,
    Mojca

Re: Request to rename version.h

[Hans-Bernhard B. <HBB...@t-...>]

Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> Dear developers,
> 
> I would like to request renaming the file version.h (and potentially
> version.c) to something else, for example gnuplot_version.h.
> 
> The problem is that C++20 introduced a standard header version.h:
>     https://en.cppreference.com/w/cpp/header/version

That's not actually what that reference says.  That header is called
<version>, not <version.h>.

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.

Re: Request to rename version.h

[Mojca M. <moj...@gm...>]

On Sun, 3 Nov 2019 at 22:33, Hans-Bernhard Bröker wrote:
> Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> > Dear developers,
> >
> > I would like to request renaming the file version.h (and potentially
> > version.c) to something else, for example gnuplot_version.h.
> >
> > The problem is that C++20 introduced a standard header version.h:
> >     https://en.cppreference.com/w/cpp/header/version
>
> That's not actually what that reference says.  That header is called
> <version>, not <version.h>.

I'm sorry, I misread the error report.

The problem is in fact not with version.h, but with VERSION (please
note that files are case insensitive on macOS).

I tried to reproduce the problem locally, and here's what I get:

/opt/local/bin/clang-mp-9.0  -pipe -Os -F/opt/local/Library/Frameworks
-arch x86_64 -ObjC  -L/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib
-L/opt/local/lib -Wl,-headerpad_max_install_names
-F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf
-framework Foundation -framework AquaTerm -L/opt/local/lib
-L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -o
bf_test bf_test.o -lm
In file included from wxterminal/wxt_gui.cpp:93:
In file included from wxterminal/wxt_gui.h:75:
In file included from
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/wxprec.h:12:
In file included from
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/defs.h:734:
In file included from
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/debug.h:14:
In file included from /usr/include/assert.h:44:
In file included from
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/stdlib.h:100:
In file included from
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/math.h:337:
In file included from
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/type_traits:417:
In file included from
/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.

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

Re: Request to rename version.h

[Ethan M. (UW) <me...@uw...>]

On Sunday, 03 November 2019 22:57:19 Mojca Miklavec wrote:
> On Sun, 3 Nov 2019 at 22:33, Hans-Bernhard Bröker wrote:
> > Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> > > Dear developers,
> > >
> > > I would like to request renaming the file version.h (and potentially
> > > version.c) to something else, for example gnuplot_version.h.
> > >
> > > The problem is that C++20 introduced a standard header version.h:
> > >     https://en.cppreference.com/w/cpp/header/version
> >
> > That's not actually what that reference says.  That header is called
> > <version>, not <version.h>.
> 
> I'm sorry, I misread the error report.
> 
> The problem is in fact not with version.h, but with VERSION (please
> note that files are case insensitive on macOS).
> 
> I tried to reproduce the problem locally, and here's what I get:
> 
> /opt/local/bin/clang-mp-9.0  -pipe -Os -F/opt/local/Library/Frameworks
> -arch x86_64 -ObjC  -L/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names
> -F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf
> -framework Foundation -framework AquaTerm -L/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -o
> bf_test bf_test.o -lm
> In file included from wxterminal/wxt_gui.cpp:93:
> In file included from wxterminal/wxt_gui.h:75:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/wxprec.h:12:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/defs.h:734:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/debug.h:14:
> In file included from /usr/include/assert.h:44:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/stdlib.h:100:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/math.h:337:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/type_traits:417:
> In file included from
> /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
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

Re: Request to rename version.h

[Ethan M. (UW) <me...@uw...>]

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

Upon further reflection...
Your error message cannot be coming from a filename.
It is the VERSION symbol itself that may be an issue.
Can you compile a junk program?

    clang -o helloworld -DVERSION="6.7" helloworld.cpp

If defining VERSION breaks your compile chain that is clearly
a problem, but it has nothing to do with gnuplot file names.

	Ethan

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

Re: Request to rename version.h

[Marcus Calhoun-L. <mca...@ma...>]

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,
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
>  
> Upon further reflection...
> Your error message cannot be coming from a filename.
> It is the VERSION symbol itself that may be an issue.
> Can you compile a junk program?
>  
>     clang -o helloworld -DVERSION="6.7" helloworld.cpp
>  
> If defining VERSION breaks your compile chain that is clearly
> a problem, but it has nothing to do with gnuplot file names.
>  
> 	Ethan
>  
> -- 
> Ethan A Merritt, Dept of Biochemistry
> Biomolecular Structure Center,  K-428 Health Sciences Bldg
> MS 357742,   University of Washington, Seattle 98195-7742

Re: Request to rename version.h

[Hans-Bernhard B. <HBB...@t-...>]

Am 04.11.2019 um 05:15 schrieb Marcus Calhoun-Lopez:

> If -I$(top_builddir) is replaced with -idirafter$(top_builddir), the problem goes away.

Unfortunately that's easier said than done, as

a) this line is part of the automatic mechanisms of GNU automake, which
we have little to no control over (that's why it appears in generated
Makefile.in, but not in the hand-written Makefile.am)
b) -idirafter is a non-standard feature, so we cannot blindly assume it
would be usable
c) because of a), we also cannot solve issue b) by making the fix depend
on the result of some configuration test

What all this means is that the solution almost certainly will have to
be to rename our VERSION file, or remove it altogether.  Both approaches
require a modification of all the places that currently use it (which
are quite a few).

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

Re: Request to rename version.h

[Hans-Bernhard B. <HBB...@t-...>]

Am 04.11.2019 um 20:20 schrieb Ethan A Merritt:

[I'll take the liberty to answer on Marcus' behalf...

> (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"     ????

No.  The change is that the C++ standard library (and not just for
C++20, but also in already existing implementations) now contains a
standard header named <version>, which it did not use to do.

That new header gets mixed up with our VERSION file on case-ignorant
file systems, and so strangeness ensues.

I'm actually surprised I'm not seeing the same issue on Windows, too, as
all the preconditions seem to be fulfilled there, too. Maybe the Windows
compilers try harder to overcome their host system's case-blindness, and
thus manage to avoid this trap.

> (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.

The applicable switch would have to be -std=c++2x, as this is a C++
issue; it does not affect C.  To inject it into the autoconf process one
would have to specifically override the CXXFLAGS, not CLAGS.

> (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.

We need to be rather careful here.  The VERSION file is used in several
places; distributed over many build platforms.

Just throwing the file away increases the number of places you would
have to remember to put the new version number into, on every release.
The whole point of the current construct of course is to limit that
number to exactly one: the VERSION file itself.  Without the VERSION
file, to get the same effect we would have to export the version number
from configure.ac (the AC_INIT call) to quite a number of places, most
of which live resolutely outside the autoconf world.

I believe the better short-term solution would be to rename the existing
file, and carry that rename through into all the affected files.  Unless
I missed some, those would be:

	config/cygwin/Makefile
	config/makefile.cyg
	config/makefile.os2
	config/mingw/Makefile
	configure.ac
	docs/titlepag.tex
	Makefile.maint
	src/Makefile.maint

And I suspect some of the other config/* files could benefit from an
update in this direction as well --- primarily those currently
hard-coding it into their config.* files or Makefiles.

Re: Request to rename version.h

[Dima K. <gn...@di...>]

Mojca Miklavec <moj...@gm...> writes:

> I tried to reproduce the problem locally, and here's what I get:
>
> /opt/local/bin/clang-mp-9.0  -pipe -Os -F/opt/local/Library/Frameworks
> -arch x86_64 -ObjC  -L/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names
> -F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf
> -framework Foundation -framework AquaTerm -L/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -o
> bf_test bf_test.o -lm
> In file included from wxterminal/wxt_gui.cpp:93:
> In file included from wxterminal/wxt_gui.h:75:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/wxprec.h:12:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/defs.h:734:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/debug.h:14:
> In file included from /usr/include/assert.h:44:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/stdlib.h:100:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/math.h:337:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/type_traits:417:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> ../version:1:1: error: expected unqualified-id
> 5.2

If I'm reading this correctly, then this is not gnuplot-related
specifically, but rather a bug in wxt. What if you run the above command
to build just

  #include <wx/wxprec.h>

If you get the same issue, then wxt is interacting poorly with whatever
the mac people are doing. Probably should report the issue to them too.

But that build command looks really suspicious; are we sure we're
understanding the issue correctly?

What is -ObjC ? Are we compiling using the language we think we are? Can
we split the compile and the link into separate commands to simplify the
test case?

/opt/local??? Do you also have stuff in /opt and in /usr and in
/usr/local? If so, are we 100% sure you're not accidentally picking up
some incompatible combination?

It'd be interesting to run with -save-temps, and then look at the .ii
you get to see what the prepreprocessor ends up doing.

Or if you're sure you understand the problem, then nobody needs to do
any of these :)

Re: Request to rename version.h

[Achim G. <Str...@ne...>]

Hans-Bernhard Bröker writes:
> No.  The change is that the C++ standard library (and not just for
> C++20, but also in already existing implementations) now contains a
> standard header named <version>, which it did not use to do.
>
> That new header gets mixed up with our VERSION file on case-ignorant
> file systems, and so strangeness ensues.
>
> I'm actually surprised I'm not seeing the same issue on Windows, too, as
> all the preconditions seem to be fulfilled there, too. Maybe the Windows
> compilers try harder to overcome their host system's case-blindness, and
> thus manage to avoid this trap.

The common file systems on Windows are case-preserving and
case-insensitive, but not case-ignoring.  Would that explain the
difference?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Request to rename version.h

[Hans-Bernhard B. <HBB...@t-...>]

Am 05.11.2019 um 20:03 schrieb Achim Gratz:
> The common file systems on Windows are case-preserving and
> case-insensitive, but not case-ignoring.  Would that explain the
> difference?

I very much doubt it.

1) And as far as I'm aware, MacOS has the same features, and does
exhibit the problem.

2) Case-preservance only makes a difference when asking a file for its
name or listing the files in a directory, but not when searching for a
file by name, along a path list.  Rather that's where the insensitivity
hits.  A path search mechanism would have to go out of its way to read
back the actual file name of any file it found, to see if the case
matches, too.

On inspection I did not find any mention of <version> in the dependency
information collected by my local compilations, though.  So possibly my
local, MinGW and Cygwin versions of the tools and libraries in question
(wxWindows, stdc++, ...) are not quite new enough to trigger the problem.

Re: Request to rename version.h

[ASSI <Str...@ne...>]

Marcus Calhoun-Lopez writes:
> 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.

So this is likely only a problem if you do an in-tree build, can you try
to build out-of-tree instead and see if that error goes away?

> If -I$(top_builddir) is replaced with -idirafter$(top_builddir), the problem goes away.

That's changing the search order which may have different problems.

Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Request to rename version.h

[Mojca M. <moj...@gm...>]

Hi,

I just got a confirmation from one of the Apple developers working on
the compiler that
    "This is (unfortunately) correct behavior from the perspective of
the toolchain"

On Tue, 5 Nov 2019 at 22:43, Hans-Bernhard Bröker wrote:
> Am 05.11.2019 um 20:03 schrieb Achim Gratz:
> > The common file systems on Windows are case-preserving and
> > case-insensitive, but not case-ignoring.  Would that explain the
> > difference?
>
> I very much doubt it.
>
> 1) And as far as I'm aware, MacOS has the same features, and does
> exhibit the problem.
>
> 2) Case-preservance only makes a difference when asking a file for its
> name or listing the files in a directory, but not when searching for a
> file by name, along a path list.  Rather that's where the insensitivity
> hits.  A path search mechanism would have to go out of its way to read
> back the actual file name of any file it found, to see if the case
> matches, too.
>
> On inspection I did not find any mention of <version> in the dependency
> information collected by my local compilations, though.  So possibly my
> local, MinGW and Cygwin versions of the tools and libraries in question
> (wxWindows, stdc++, ...) are not quite new enough to trigger the problem.

I tried to reproduce the problem on msys2 (MinGW64) on Windows. I
could easily reproduce the problem with:

$ cat VERSION
1.0

$ cat test.cpp
#include <version>
int main() { return 0 }

$ clang++ test.cpp -I.

but on macOS I also get the problem with as trivial minimal example as

$ cat test.cpp
#include <memory>
int main() { return 0 }

The main difference is that the included file <memory> on MSYS2
apparently comes from FSF (the header mentions the licence GPL v3),
it's thus a completely different header and as a consequence one
doesn't immediately see the same behaviour. But if I edit the "memory"
file and only add
    #include <version>
there, then the local VERSION file is picked up, so it's basically the
same behaviour as on macOS.

$ clang++ test.cpp -I.
In file included from test.cpp:1:
In file included from
C:\Programs\MSYS\msys64\mingw64\include\c++\9.2.0\memory:3:
.\version:1:1: error: expected unqualified-id
1.0
^
1 error generated.

So all in all, I would be really grateful if VERSION file could be renamed.

(According to our limited opt-in installation statistics, gnuplot seem
to be the 21st most popular explicitly installed package, and having
it broken is not really the best option. We monkey-patched it for now,
but it would be great to have a proper solution in place.)

Mojca

Re: Request to rename version.h

[Ethan M. (UW) <me...@uw...>]

On Monday, 11 November 2019 09:35:03 Mojca Miklavec wrote:
> Hi,
> 
> I just got a confirmation from one of the Apple developers working on
> the compiler that
>     "This is (unfortunately) correct behavior from the perspective of
> the toolchain"

I have extended the trial patch to include modification of the file
   config/mingw/Makefile

So far as I can see, the other config files mention by Hans-Bernard 
are fine once dependence on $(TOP)/VERSION is removed.  They only use
it to prepare the TeX/PDF build, which was already handled directly as
a modification to docs/titlepag.tex

Please confirm if this patch works for you.

	Ethan

> 
> On Tue, 5 Nov 2019 at 22:43, Hans-Bernhard Bröker wrote:
> > Am 05.11.2019 um 20:03 schrieb Achim Gratz:
> > > The common file systems on Windows are case-preserving and
> > > case-insensitive, but not case-ignoring.  Would that explain the
> > > difference?
> >
> > I very much doubt it.
> >
> > 1) And as far as I'm aware, MacOS has the same features, and does
> > exhibit the problem.
> >
> > 2) Case-preservance only makes a difference when asking a file for its
> > name or listing the files in a directory, but not when searching for a
> > file by name, along a path list.  Rather that's where the insensitivity
> > hits.  A path search mechanism would have to go out of its way to read
> > back the actual file name of any file it found, to see if the case
> > matches, too.
> >
> > On inspection I did not find any mention of <version> in the dependency
> > information collected by my local compilations, though.  So possibly my
> > local, MinGW and Cygwin versions of the tools and libraries in question
> > (wxWindows, stdc++, ...) are not quite new enough to trigger the problem.
> 
> I tried to reproduce the problem on msys2 (MinGW64) on Windows. I
> could easily reproduce the problem with:
> 
> $ cat VERSION
> 1.0
> 
> $ cat test.cpp
> #include <version>
> int main() { return 0 }
> 
> $ clang++ test.cpp -I.
> 
> but on macOS I also get the problem with as trivial minimal example as
> 
> $ cat test.cpp
> #include <memory>
> int main() { return 0 }
> 
> The main difference is that the included file <memory> on MSYS2
> apparently comes from FSF (the header mentions the licence GPL v3),
> it's thus a completely different header and as a consequence one
> doesn't immediately see the same behaviour. But if I edit the "memory"
> file and only add
>     #include <version>
> there, then the local VERSION file is picked up, so it's basically the
> same behaviour as on macOS.
> 
> $ clang++ test.cpp -I.
> In file included from test.cpp:1:
> In file included from
> C:\Programs\MSYS\msys64\mingw64\include\c++\9.2.0\memory:3:
> .\version:1:1: error: expected unqualified-id
> 1.0
> ^
> 1 error generated.
> 
> So all in all, I would be really grateful if VERSION file could be renamed.
> 
> (According to our limited opt-in installation statistics, gnuplot seem
> to be the 21st most popular explicitly installed package, and having
> it broken is not really the best option. We monkey-patched it for now,
> but it would be great to have a proper solution in place.)
> 
> Mojca
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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