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