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: Sat, 10 Sep 2011 23:35:15 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2

Den 2011-09-10 02:22 skrev Bruno Haible:
> Peter Rosin wrote:
>> The platform name was discussed a few years back on the libtool lists (I
>> think somewhere in the gigantic thread "[patch #6448] [MSVC 7/7] Add MSVC
>> Support" from August 2008 approximately) [0], the outcome was that compiling
>> with cl for the MS C runtimes uses the same triplet as compiling with
>> gcc for the MS C runtimes. I.e. *-*-mingw32.
> 
> Actually, the set of triplets is not defined by libtool, but by config.sub.
> In config.sub the *-*-mingw32 appears to be in use for this platform already
> since May 2005 (see [1][2][3][4]).

>From time to time, I'm wondering if reusing *-*-mingw* for cl is the
right decision. The main benefits that I see are that you don't have to
cross compile if you are in MSYS and the special casing needed for MinGW
is generally needed for MSVC as well, so you don't have to sprinkle extra
variations for *-*-winnt* to a bunch of case statements.

> Fine with me. But in gnulib, we will have to make the distinction between
> mingw and msvc, because on mingw, the library libmingwex is part of the
> default runtime libraries, and it defines lots of symbols, from 'acosf' to
> 'wtoll'.

I'm ignorant to the details, so there's probably some good reason why that
isn't covered by func-by-func feature tests using the normal Autoconf paradigm?
I'm sure libmingwex is a lib that evolves, so gnulib presumably has to deal
with different levels of help from it. No help at all is just an extreme
of that (and some gnulib modules apparently needs to be updated to support
that extreme).

>> So, just drop the --host argument. (if you run in an MSYS shell, which I
>> assume?)
> 
> No, MSYS is too unreliable, I can't recommend that. 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

Other parts of the build system might not provide similar support, but if
you are in MSYS, MSYS is doing all the faking for you, so there's no need
to tell Libtool or anybody else.

(and for the record, my MSYS install seems very reliable to me)

Cheers,
Peter



reply via email to

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