libtool-patches
[Top][All Lists]
Advanced

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

Re: MSVC: Add MSVC support.


From: Ralf Wildenhues
Subject: Re: MSVC: Add MSVC support.
Date: Thu, 24 Jun 2010 06:51:42 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* Peter Rosin wrote on Wed, Jun 23, 2010 at 11:43:41PM CEST:
> Den 2010-06-23 20:29 skrev Ralf Wildenhues:
> >Please rewrite this ChangeLog entry to be a good one, mentioning the
> >macros you change, the systems, compilers affected, in the format
> >used otherwise in the ChangeLog.
> 
> Ouch. That was a pretty bad entry indeed. Is this good enough?
> 
> 2010-06-23  Peter Rosin  <address@hidden>
> 
>       Add MSVC support.
>       * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
>       (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG) [mingw, cygwin]: Add
>       support for the Microsoft C/C++ Compiler (cl) relying on help
>       from the compile script in Automake.
>       * NEWS: Add note of the above.

Yes.

> >>--- a/NEWS
> >>+++ b/NEWS

> >>+* Changes in supported systems or compilers:
> >>+  - Initial support for the Microsoft C/C++ Compiler w/o cccl.
> >
> >Please no abbreviations like w/o here, this is text for the user.  Also,
> >the 'compile' script is needed now, no?
> 
> How about this:
> 
> * Changes in supported systems or compilers:
>   - Initial support for the Microsoft C/C++ Compiler with help from
>     (proposed changes to) the compile script in Automake.
> 
> And then fiddle the NEWS entry to specify the needed Automake version
> when one is known?

How about "for unreleased Automake 1.12", that should be safe.

> >It strikes me as a bit inconsistent that here, the default case will be
> >g++, and above, the default case is non-GCC.  I'm not actually sure
> >which is better, in the presence of other compilers users want to see
> >supported, but I think we should be consistent in handling between C and
> >C++.
> 
> It's just the way it is. In the C case, there is a big divider between
> GNU and non-GNU. For C++ it all jumbled together. "Fixing" that is out
> of scope I presume. The difference is perhaps even more visible by the
> fact that the cccl port (if it even deserves to be called a port) is
> not C++ aware AFAICT.

OK.

Thanks,
Ralf



reply via email to

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