RE: [patch #6448] [MSVC 7/7] Add MSVC Support

[Duft Markus]

> 
> Den 2008-08-26 13:53, skrev Peter Rosin:
> > Charles Wilson skrev:
> >> I also think that -winnt is too broad; and I'd really hate to see
> the
> >> massive uglification of the libtool code -- and thousands of
> >> configure.ac's out there -- that would ensue if -mingw* were
> >> /officially/ overloaded to also represent the msvc-toolchain case.
> >
> > Thanks a bunch for that. Where specifically is this "massive
> > uglification" in the pr-msvc-support branch?
> 
> Ok, I ended up spending the evening doing an experiment: I grabbed
> a package at random, it happened to be libsndfile, and made it build
> with MSVC (I selected it before I had a look at the code, I only
> checked if it was using libtool, v1.5.22, so I updated it to
> pr-msvc-support + patches waiting for review). The problems I
> encountered were:
> 
> * snprintf is spelled _snprintf (worked around elsewhere, code
>    has apparently been ported at some point, but suffered a bit
>    of bitrot)
> * inline is spelled __inline (added AC_C_INLINE)
> * cl does understand -c -o (added AM_PROG_CC_C_O)
> * MSVC does not have unistd.h (commented it out a few times,
>    found #if HAVE_UNISTD_H elsewhere in the code...)
> * truncate() definition ifdeffed away (_WIN32 spelling bad, the
>    code had #ifdef __WIN32, typo?)
> * MSVC does not have the __func__ macro (defined it to "").

I assume __func__ contains the current function name? If yes, those are
the closest matches from MSDN:

__FUNCDNAME__
 Valid only within a function and returns the decorated name of the
enclosing function (as a string). __FUNCDNAME__ is not expanded if you
use the /EP or /P compiler option.
 
__FUNCSIG__
 Valid only within a function and returns the signature of the enclosing
function (as a string). __FUNCSIG__ is not expanded if you use the /EP
or /P compiler option.
On a 64-bit operating system, the calling convention is __cdecl by
default.
 
__FUNCTION__
 Valid only within a function and returns the undecorated name of the
enclosing function (as a string). __FUNCTION__ is not expanded if you
use the /EP or /P compiler option.

> etc
> 
> I.e. small stuff that affects the code, not the build system,
> and $host has no bearing whatsoever.
> 
> Then there are two things which seem connected to $host mingw*
> that would be the source of the "massive uglification" in the
> build files.
> 
> 1) libsndfile seems to want to kill signed/unsigned warnings
> caused by sizeof, by defining a SIGNED_SIZEOF macro, the contents
> of this macro is hardcoded when $host is mingw*, and the
> definition is bad for MSVC (it uses int64_t).

You're lucky that there is only one such small thing. I saw packages
hardcoding _lots_ of things based on $host.

> 
> 2) the ordinals in the built dll doesn't pass the testsuite
> (but they don't do that with mingw-gcc either, perhaps because
> I built out of tree? I had to do some tweeks to make that
> work, maybe I missed something...). libsndfile passes the .def
> file directly to the linker using -Wl, when it is using gcc.

Assuming that the compiler/linker understands certain options based on
$host is seen quite often. Especially with mingw, since mingw is the
name of a _compiler_. Can't you see, that mingw32 is the compiler? Maybe
you use msys as your environment, yes, but mingw is not involved at all
in you compilations... How can you expect users to _not_ be confused
when they think of mingw and get cl.exe? Calling your host ming32 feels
just really really wrong, since your port has absolutely nothing (and
really _nothing_ to do with mingw. What if somebody uses your port on,
say, interix or cygwin? He doesn't necessarily need to know about mingw
at all!

> 
> For 1) a proper autoconf test would solve this and clean up the
> code at the same time.

Sure, but I guess you won't get that message to 300 package maintainers
if that means additional work. Those people will tell you: "hey, I have
working windows support already, I don't need your stuff, so I won't put
hours into cleaning up mingw"... even if things work out of the box,
people are unlikely to use it, if they have another solution already (I
saw that with parity)...

> 
> For 2) libsndfile doesn't set an export file unless you build
> with gcc, so it would be easy to add the correct argument when
> building with MSVC, without causing any extra clutter. And if
> the code is changed to use the libtool option -export-symbols
> instead of using -Wl, I think MinGW and MSVC can use the same
> export file, including ordinal specification. But I haven't
> tested that (you should be able to pass a .def file straight
> through to the linker using -export-symbols by having the first
> line read EXPORTS, for both MinGW and MSVC).

Mhm, sounds as i fit can work :)

> 
> If I make the testsuite ignore the ordinals problem, and manually
> fix the SIGNED_SIZEOF problem all other tests pass (there are
> quite a few).
> 
> I realize that one random package doesn't say much. But one
> tweek (or two, maybe maybe two) inside mingw* territory is
> definitely not "massive uglification", not when there is room
> for unification. Or?

As I said above, I feel mingw is just plain wrong... but it's your
patch, you will know. :)

Cheers, Markus

> 
> Cheers,
> Peter
>