Re: [lmi] MinGW-w64 gcc-6.3.0 anomaly

[Vadim Zeitlin]

On Fri, 26 Apr 2019 18:53:23 +0000 Greg Chicares <address@hidden> wrote:

GC> It's time to reopen this old thread, which begins in the archives here:
GC>   http://lists.nongnu.org/archive/html/lmi/2017-08/msg00017.html

 Thanks for the context (here and in the parts I removed), it helps to
understand the problem, but I'm not really certain what is our actual goal
here. First of all:

GC> On 2017-08-20 17:58, Greg Chicares wrote:
[...]
GC> > The compiler simply fails, returning "1" with no diagnostic.
GC> > It succeeds only if the compiler's binary path is on $PATH:
[...]
GC> > This is of course regrettable: it makes it unreasonably
GC> > difficult to use other compilers that might also provide
GC> > binaries with names like 'cpp.exe'.

 Is this really a concern in practice? In the intervening years we've
changed the compiler a couple of times and so I now have 3 or 4 of them in
my lmi VM, and it has never been a problem to set PATH appropriately before
using them. I.e. I'm simply not sure that there is an actual problem here
to begin with.

GC> Now I want to...
GC> 
GC> https://lists.nongnu.org/archive/html/lmi/2019-04/msg00023.html
GC> 
GC> | Copy all required libraries as well as lmi's own binaries, so that
GC> | each $INSTALL directory would have a complete set and there'd be no
GC> | need to alter any path variable in the environment.

 I do understand this goal, but I don't think we should include the DLLs
needed only by the compiler and not by lmi itself in the list of "required
libraries".

GC> (1) Revert a06270feeb and fix the problem in a better way: by
GC> copying compiler runtime files to the build directory whenever
GC> it's entered. I'm assuming that no one ever enters that directory
GC> directly, and everyone instead uses 'GNUmakefile" to enter it,

 I did execute commands directly in this directory when I wanted to specify
some make flags that couldn't be easily passed through the main GNUmakefile
but it's a special case and I could just set the PATH directory anyhow,
i.e. it's not really an objection.

GC> (2) Copy the compiler runtime files directly from their origin,
GC> in the 'install' target, as before a06270feeb was committed.

 Why not.

GC> IOW, I consider a06270feeb a poor fix, and it happened to
GC> create an obstacle for the intended 'install' enhancement,
GC> so I reverted and replaced it, then proceeded with the
GC> enhancement. Of course, as always, I might have made it worse,
GC> so careful review and testing are welcomed (pushing now).

 I don't think you made anything worse, but I'm not sure what has become
significantly better neither. Maybe it's just because I'm tired right now
and I'll understand it when I look at this again tomorrow, but I really
don't see anything wrong with just adding the compiler directory to the
PATH. Moreover, couldn't GNUmakefile modify the PATH in MAKETARGET, i.e. do
it automatically before invoking workhorse.make?

 There is nothing terribly wrong with copying a couple of DLLs around, of
course, but IMHO it would be even better if we could avoid doing this.

 Sorry if I'm missing something obvious here,
VZ