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, 03 Sep 2011 19:39:38 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1

Den 2011-09-03 00:43 skrev Michael Goffioul:
> On Fri, Sep 2, 2011 at 11:26 PM, Peter Rosin <address@hidden> wrote:
>> The web has a couple of different forked versions of cccl. What is
>> the "upstream" for that script? There is ancient support for some
>> version of cccl in libtool, but I didn't get it to work with any
>> version of cccl that I found (some things might have worked, but
>> there were loads of failures for simple things in the libtool
>> testsuites. I have forgotten the details so don't ask...). So, I
>> didn't want to create yet another fork of cccl, and instead fixed
>> the 'compile' script in Automake to handle the bits that must be
>> handled by the build tools (and taught libtool to deal with cl
>> natively). What I didn't do was add all sorts of options to
>> 'compile' to make cl look like gcc, because that way lies madness.
>> Packages aiming for portability shouldn't assume gcc in the first
>> place. End result, you have to feed optimization options and such
>> in the way cl expects them.
>>
>> There is also the 'ar-lib' script that does the bare minimum to
>> present a posixy archiver interface (albeit incomplete) to Microsoft
>> lib, in a similar manner that 'compile' makes cl understand the
>> -l and -L options (and a few others).
>>
>> All in all, I regularly use these scripts to build packages with
>> cl, and the configure.ac/Makefile.am of those packages need not
>> do special things to have it all work.
>>
>> A typical configure invocation might be (from an MSYS shell):
>>
>> .../configure CC="cl -nologo" CFLAGS=-MD LD=link NM="dumpbin -symbols" \
>>  AR="/home/peda/automake/lib/ar-lib lib" STRIP=: RANLIB=: \
>>  --enable-dependency-tracking
>>
>> configure.ac needs to have AM_PROG_CC_C_O which might not be one of
>> the most common macros, but that's certainly not too bad. And when
>> the mentioned branch in Automake git is merged I imagine there will be
>> a macro named something like AM_PROG_AR that will make it sufficient
>> to say AR=lib to configure, instead of pointing at 'ar-lib' explicitly.
>>
>> I don't think cccl is the future, I see it as the past. It's
>> simply not needed when the needed bits are already in 'compile'.
>>
>> It's a bit sad to see all the effort going into writing private
>> scripts wrapping cl into something that looks like gcc, when the
>> effort could be spent making autotools just work instead.
> 
> I'd be happy to give those scripts a try when I get some time. I guess I have 
> to
> download/install autoconf/automake/libtool from git. Anything else?

Libtool 2.4 should do, and (I think) you only need the 'compile' and
'ar-lib' scripts from automake-git-master to try them.

> When you want to compile a package, I guess you then have to rerun
> autoconf/automake to get updated compilation scripts?

That's one way, but you can also just point to a new enough compile/ar-lib

> When configure.ac does not contain then AM_PROG_CC_C_O macro,
> what do you do? Add it manually? For instance I checked PCRE code
> (http://vcs.pcre.org/viewvc/code/trunk/configure.ac?revision=666&view=markup)
> and couldn't find that macro.

In that case, as stated above, you can just use compile/ar-lib as you'd
use cccl, the macros only trigger the use of the scripts when they are
needed (and the inclusion of the scripts in the package). If you know
that you need them it's not wrong to point to them from the start (as I
did for AR in above example configure invocation).

Cheers,
Peter



reply via email to

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