automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf + automake support for MSVC


From: Peter Rosin
Subject: Re: autoconf + automake support for MSVC
Date: Sun, 11 Sep 2011 18:50:11 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2

Den 2011-09-11 00:04 skrev Bruno Haible:
> Peter Rosin wrote:
>> The main benefits that I see are that you don't have to
>> cross compile if you are in MSYS
> 
> You have the wrong notion of "cross compile", if you think cross-compiling
> means that $host != $build. When I am building for i386-pc-linux-gnu from
> a x86_64-pc-linux-gnu machine, I am *not* cross-compiling. When you are
> building for i586-pc-mingw32 from i586-pc-cygwin, you are *not* cross-
> compiling. Cross-compiling means that the generated executable can not be
> run on the build machine.

I don't think I have the wrong notion, but I got insecure by your statement
and decided to read the fine Autoconf manual. I ended up reading the following
section back and forth a couple of times...

http://www.gnu.org/software/autoconf/manual/autoconf.html#Hosts-and-Cross-Compilation

The way I read it, I can see that you can get to your view of things *if*
you live in the Autoconf 2.13 era (10 years ago), but even then I don't
think your view has ever been the intended definition of a cross (but I
don't know).

How can a cross not be a cross anymore just because someone has installed
an emulator? That seems entirely bogus to me.

If you use Autoconf in the way the Autoconf manual advises, you should pass
both --host and --build to configure (if you specify any of them) and
Autoconf enters cross-compile mode if they are different. End of story?

> It can be necessary to use cygpath also when not cross-compiling. Gladly,
> the Automake emitted build uses it, and the 'compile' script from the
> Automake 'msvc' branch uses it as well.

Huh? I'm sure I disagree because we have different views of what a cross is.
In what event is cygpath needed to build a package for Cygwin using Cygwin
tools in a Cygwin environment? Maybe for some package trying to outsmart
Cygwin or otherwise access Win32 directly, but that's not your average
package...

>>> I use Cygwin as a build environment.
>>
>> But then you are in the 'fake' cross territory (according to the terminology
>> of the libtool manual), which is also not always desirable. E.g., if you use
>> absolute path names (I'm sure you try to avoid them) and Libtool, you need
>> to tell Libtool that you are faking the cross compile with an extra configure
>> argument:
>>
>>      lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
>>
>> See http://www.gnu.org/s/libtool/manual/libtool.html#Cygwin-to-MinGW-Cross
> 
> I am not faking a cross-compile; I am not cross-compiling at all.
> Libtool needs to be fixed to use cygpath when needed, without requiring an 
> extra
> configure argument. That configure argument is implicit from $host and $build.

According to the Libtool manual, you are "faking" it. Live with it :-)
And why should it be the duty of Libtool to tidy up after your "obsolete",
"do not rely on the following" (according to the Autoconf manual) use of
configure?

>> MSYS is doing all the faking for you
> 
> It does it in a buggy way. I pass the argument "/dev/null" to a program, and
> the MSYS execve call silently converts it to "nul" (or vice versa, I don't
> remember). That's not reliable, because not all program arguments are meant
> to be file names. To do it correctly, file name conversions need to be 
> explicit.
> That's what cygpath is for.

Well, nul (or NUL: or whatever the exact translation is) is to Win32 what
/dev/null is to Posix, so that example is by design. You don't like that
design decision, but in my book it's a bit harsh to call that particular
feature a bug.

The whole point of MSYS is to provide automatic path translation, it's
the defining difference between Cygwin and MSYS. The fact that you can't
do it perfectly is why the Cygwin project rejects the temptation. But for
the majority of cases where it works it is very handy. When it doesn't
work it is of course obnoxious, but that is just the way it is. You can't
eat the cake and still have it.

Cheers,
Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]