Re: MSVC: Add MSVC support.

[Peter Rosin]

Den 2010-06-23 20:29 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Wed, Jun 23, 2010 at 04:26:22PM CEST:
> > For this patch I'm looking for an ok to commit, but
> > I'm going to hold the actual commit until I have done
> > a couple of more things:
> >
> > * I have a similar ok for one more patch (.manifest
> >    related, 9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5)
> > * I have run the testsuite on Cygwin, MinGW/gcc and
> >    MinGW/msvc and verified that there are no regressions.
>
> You have my OK to commit this patch, provided that you do the above
> testing, address the nits below, and wait 72h for other comments.
> Thanks.

Cool!

> > * maybe (if you think I should) wait for the proposed
> >    compile script to be commited to automake.
>
> Not for me.  If you want this available somewhere then I suggest you put
> Automake plus your proposed patches up on a github somewhere until the
> copyright assignment is done, which might easily take weeks.  Please
> make it clear in the .git/description that it is not an official tree.

That's not worth it. At least not to me...

> > +2010-06-23  Peter Rosin<address@hidden>
> > +
> > +       Add MSVC support.
> > +       * libltdl/m4/libtool.m4: Add support for Microsoft Visual C.
> > +       * NEWS: Add note of the above.
>
> 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.


> > --- a/NEWS
> > +++ b/NEWS
> > @@ -7,6 +7,9 @@ New in 2.2.12 2010-08-??: git version 2.2.11a, Libtool team:
> >     - On non-cygwin Windows systems, we now lookup potential library
> >       file names without regard to file name case.
> >
> > +* 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?

> > +  yes,* | yes,* | yes,*)
>
> `X | X | X' is equivalent to `X'.

How silly. *fixing*

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

Cheers,
Peter