[Top][All Lists]
[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