Re: Using Perl's cc

[Eli Zaretskii]

> Date: Fri, 3 Jul 2015 22:15:25 +0100
> From: Gavin Smith <address@hidden>
> Cc: address@hidden
> 
> On 3 July 2015 at 21:47, Eli Zaretskii <address@hidden> wrote:
> > The MinGW build process uses MSYS tools, which allow to run Posix
> > scripts and Makefiles to build MinGW (i.e. native Windows) programs.
> > These MSYS tools, including Perl, use a different (and incompatible)
> > runtime, so even if the extension could be built, it would not work
> > for one of the two Perl binaries.  Whereas the design of this feature
> > most probably assumes that the same Perl is used on both occasions.
> 
> Why does the MSYS installation of Perl have to be used at all?

Because when a Perl script invokes /usr/bin/program, or references
/dev/tty or /dev/stdout, a native Windows build of Perl will not be
able to DTRT.  And because shell scripts expect Perl to produce
Unix-style EOLs in their output.  And for umpteen other subtleties
that can make running a build a nightmare on Windows.  The MSYS
toolchain makes all that magically work, which is its single most
important raison d'être.  Its only problem is that its development
stagnated, so even its Perl is not 100% up to the texi2any job (it
spits out 2 non-fatal warnings while processing the Emacs Lisp
Reference manual).

> It's like compiling against a shared library, and then trying to use
> it against an incompatible version of it.

Yes.  But normally, a build of a package doesn't need to build
libraries that link against the tools used during the build.  You
produce libraries that will need to link against the products of the
build.  And that works, because the compiler and Binutils used during
the build are MinGW (_not_ MSYS!) compiler/Binutils, and so they use
the MinGW runtime.

> > That project comes with its own version of MinGW and the rest of the
> > development tools, which is too much.  I, for one, will never let any
> > distribution to overwrite my carefully configured and tuned MinGW
> > development environment: I worked too hard on having that set up.
> 
> Can't the two be installed in parallel?

Yes, with enough care (you need to carefully segregate your PATH, and
have scripts to switch between the two).  But there will always be
problems.  E.g., when I build Texinfo, I must have my "normal" MinGW
on PATH, to have the compiler found by Make, so then the "alternative"
MinGW will not be the first one on PATH, and I think you see the
consequences.

It might be possible to solve that, by removing the MinGW that came
with Perl, and reconfiguring it to use the existing MinGW
installation.  But that is something we cannot expect ordinary users
to do.

> What's the alternative, anyway?

Are there ways to produce C or C++ code from Perl, or compile a Perl
program into native code?  After all, the goal is speeding up
makeinfo, not using external modules, right?

Or maybe Someone™ should reimplement texi2any in C++ or some similarly
efficient language?

Just dreaming...