Re: autoconf + automake support for MSVC

Peter Rosin skrev 2011-10-19 18:03: > Stefano Lattarini skrev 2011-10-19 15:59: >> On Wednesday 19 October 2011, Peter Rosin wrote: >>> Stefano Lattarini skrev 2011-09-03 09:41: For what concerns this: are you willing to re-submit your patch series about AM_PROG_AR to automake-patches? I

Re: autoconf + automake support for MSVC

Stefano Lattarini skrev 2011-10-19 15:59: > On Wednesday 19 October 2011, Peter Rosin wrote: >> Stefano Lattarini skrev 2011-09-03 09:41: >>> For what concerns this: are you willing to re-submit your patch >>> series about AM_PROG_AR to automake-patches? I will try hard to >>> look into it, if you

Re: autoconf + automake support for MSVC

On Wednesday 19 October 2011, Peter Rosin wrote: > Stefano Lattarini skrev 2011-09-03 09:41: > > For what concerns this: are you willing to re-submit your patch > > series about AM_PROG_AR to automake-patches? I will try hard to > > look into it, if you are willing to do the required testing and >

Re: autoconf + automake support for MSVC

Stefano Lattarini skrev 2011-09-03 09:41: > For what concerns this: are you willing to re-submit your patch > series about AM_PROG_AR to automake-patches? I will try hard to > look into it, if you are willing to do the required testing and > to patiently explain to me the details I won't undertand

Re: autoconf + automake support for MSVC

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-l

Re: autoconf + automake support for MSVC

Bruno wrote: > Cross-compiling means that the generated executable can not be run on > the build machine. Is that different from executables generated on the build machine cannot be run on the host machine? H

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > my MSYS install seems very reliable to me The groff people have made a different experience. See -- In memoriam Sergei Tretyakov

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > From time to time, I'm wondering if reusing *-*-mingw* for cl is the > right decision. I think so, yes. mingw and msvc share the same kernel, the same object file format, and large parts of the C library. But it definitely ought to be documented, because it is very non-obviou

Re: autoconf + automake support for MSVC

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 >> w

Re: autoconf + automake support for MSVC

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 trip

Re: autoconf + automake support for MSVC

Den 2011-09-09 19:27 skrev Bruno Haible: > But since not all packages use the AM_PROG_CC_C_O macro (only the use of > source files in directories without a Makefile.in requires it), I would > better recommend to everyone to use CC="/path/to/compile cl -nologo" > from the beginning. But don't forge

Re: autoconf + automake support for MSVC

Den 2011-09-09 19:00 skrev Bruno Haible: > Peter Rosin wrote: >>> When configure.ac does not contain then AM_PROG_CC_C_O macro, >>> what do you do? Add it manually? ... >> >> 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

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > >> 'compile' makes cl understand the > >> -l and -L options (and a few others). > > > > So, if I understand it right, you *don't* want to assume that $CC > > understands -l and -L options, like the C compiler in POSIX does for > > ages (cf. > >

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > > When configure.ac does not contain then AM_PROG_CC_C_O macro, > > what do you do? Add it manually? ... > > 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 inclu

Re: autoconf + automake support for MSVC

On Tuesday 06 September 2011, Peter Rosin wrote: > Den 2011-09-03 09:41 skrev Stefano Lattarini: > > Oh, also, before doing that, could you please merge the 'maint' > > branch into the 'msvc' branch? Or I can do that for you if you > > prefer (but then you'll have to double-check that the merge has

Re: autoconf + automake support for MSVC

Den 2011-09-03 09:41 skrev Stefano Lattarini: > Oh, also, before doing that, could you please merge the 'maint' > branch into the 'msvc' branch? Or I can do that for you if you > prefer (but then you'll have to double-check that the merge has > been really successfull). I have now merged maint int

Re: autoconf + automake support for MSVC

On Saturday 03 September 2011, Peter Rosin wrote: > Hi Stefano, > > Den 2011-09-03 09:41 skrev Stefano Lattarini: > > On Saturday 03 September 2011, Peter Rosin wrote: > >> > >> [BIG SNIP] > >> > >> I don't think cccl is the future, I see it as the past. It's > >> simply not needed when the needed

Re: autoconf + automake support for MSVC

Hi Stefano, Den 2011-09-03 09:41 skrev Stefano Lattarini: > On Saturday 03 September 2011, Peter Rosin wrote: >> >> [BIG SNIP] >> >> 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

Re: autoconf + automake support for MSVC

Den 2011-09-03 03:47 skrev Bruno Haible: > Peter Rosin wrote: >> 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 w

Re: autoconf + automake support for MSVC

Den 2011-09-03 00:43 skrev Michael Goffioul: > On Fri, Sep 2, 2011 at 11:26 PM, Peter Rosin 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 w

Re: autoconf + automake support for MSVC

Hi Peter. On Saturday 03 September 2011, Peter Rosin wrote: > > [BIG SNIP] > > 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

Re: autoconf + automake support for MSVC

On Fri, Sep 2, 2011 at 11:26 PM, Peter Rosin 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 thing

Re: autoconf + automake support for MSVC

Peter Rosin wrote: > 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 m

Re: autoconf + automake support for MSVC

Den 2011-09-02 23:11 skrev Bruno Haible: > Ralf Wildenhues wrote in > : Windows+MSVC. I know this is not a gnulib target. >>> >>> Yes. But it could become a gnulib target if the $CC wrapper script was >>> agreed >>> upon in G