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

[Duft Markus]

> 
> Not sure if I should drag this further along...

So this is the last one ... :)

> 
[snip]
> > __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.
> 
> Ok, on a first glance those seem like better matches than "" :-)

;)

> 
> >> 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.
> 
> The question here is if you see "thousands" of packages with
> "massive" amounts of such hardcoding. It is also a question if the
> maintainers of those packages are indeed going to bother about MSVC
> at all, no matter exactly what changes are required to the build
> system. Since MSVC is so ignorant of standards it will probably be
> ignored by many. Maintainers just don't want the uglification in
> the code, and my guess is that any uglification in the build system
> is minor in comparison to the crap needed to get the code to
> compile at all.

Ok, this point is true, yes.

> 
> >> 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?
> 
> For the packages that I regularly use (and the reason for my libtool
> work), the things that are common between MinGW and MSVC outnumber
> the differences (if you talk about build system issues where $host
> matters, the actual code is something else...).
> 
> That's my reason for sticking to mingw*, I also realize that it might
> not be the best thing to do. I'm open to change, but I need arguments
> that hold.

But it cannot be even much work to simply add a new host everywhere
(except for the locations where there are differences) additionally to
mingw...? it took me a few minutes to do this for winnt/interix (I first
had interix as host, which is wrong). Then you'd have a clean
distinction of the both.

> 
>  >  Maybe
> > you use msys as your environment, yes, but mingw is not involved at
> all
> > in you compilations...
> 
> Of course MinGW is not involved, that's the whole point.

So if mingw isn't there, the host can't be mingw ...?

> 
> >  How can you expect users to _not_ be confused
> > when they think of mingw and get cl.exe?
> 
> Err, they just don't "get" MSVC imposed on them, they also have to
> say CC=cl etc etc.

what if you do "./configure --host=i586-pc-winnt-msvc" and have a link
called i586-pc-winnt-msvc-cl to cl.exe? that would make configure select
that compiler automatically.

[snip]
> 
>  >  What if somebody uses your port on,
> > say, interix or cygwin? He doesn't necessarily need to know about
> mingw
> > at all!
> 
> It's currently not possible to not use MSYS with pr-msvc-support,
> since neither Interix nor Cygwin translates filenames on the
> command line from Posix style to Win32 style (automatically, that
> is). But if libtool could be made to use cygpath etc, *everywhere*
> it's needed, I suspect it would be as any other cross compile,
> with all problems and shortcomings involved with that.

Mhm, yeah thats true with plain cl.exe, right.

> 
> How do you use MinGW from Interix? To minimize surprices I suspect
> you do it as you do it on any *nix, i.e. as a cross compiler. How
> do you use MinGW from Cygwin? Soon you will do it as you do on any
> *nix (the -mno-cygwin confusion is on its way out), i.e. as a
> cross compiler. How do you use MSVC from Interix/Cygwin? MSVC is
> not available as a cross compiler, so you will have to jump thorugh
> hoops to make it work (i.e. wrap it in a script of some sort) and
> if you fool the other build tools that you are a native compiler
> while you're at it, you also get away from the usual cross build
> limitations.
> 
> But you are still doing a cross build. If you don't realize
> that, think of the case were a testsuite has a program that
> takes a filename as argument. If you don't special case anything
> the build tools will pass that filename using Posix semantics,
> and the testsuite may fail because of it.

Parity is my wrapper, and - thats one oft he cool points - it teaches
any binary it compiles to handle three different possible types of paths
correctly: native win32 (C:\...), interix through psxdll.dll
(/dev/fs/C/..., or /usr/local/...) and cygwin through cygwin1.dll
(/cygdrive/..., /usr/local/....). this happenes completely in the
background, no additional work to be done by the package. Of course I
know that this is not possible with plain cl.exe

So for what I do, I don't feel it's a cross compile, as you can see...

> 
> How do you use MinGW from MSYS? Gosh, MSYS does the path
> translation for me! Thank you very much, I don't need a wrapper.
> IMHO, MSYS is the Posixy scripting environment that is closest to
> being native Win32, and config.guess recognizes MSYS as something
> like i686-pc-mingw32. And hey, on MSYS "uname -s" (the "kernel
> name", or the "name of the operating system" according to various
> man pages!), is something like MINGW32_NT-5.1. So, I guess it's
> not only the compiler that is named MinGW...

Hm, yeah, that must be because msys is tighly coupled with mingw.

> 
[snip]
> 
> This is of course the perfect argument why this discussion does not
> matter at all. The population of package maintainers caring about
> MSVC is probably tiny, if they go for Windows, they will go for
> MinGW and be satisfied with that.
> 
> My experiment was not an argument that using $host mingw* for MSVC
> is the best way to go, it was an attempt to refute the "massive
> uglification" argument. I felt that was on the border to FUD.

Which wasn't my argument, although i agree, that a separate host would
make things clearer and more readable, not only having the end-user in
mind, but also the libtool dev that comes in 2 years and tries to read
it... or another person trying to write something based on libtool, or
do new platform ports.

> 
> >> 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 :)
> 
> Yeez, I had an unresonably hard time parsing that, s/i fit/if it/ :-)


lol

> 
> >> 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. :)
> 
> And besides, it's fun fun fun to add windows*, win32*, winnt*,
> winxp*, win* or whatever it ends up being called, to those
> case $host_os statements. Pick your poison.

Hmm... why not look for mingw, and add winnt-msvc? It wasn't so much of
a pain for me...

> 
> All of the theories about what name to use are pointless, really.
> It all boils down to what is practical, and I need some evidence
> that using mingw* for MSVC on MSYS really is b0rked before I agree
> to change. Using mingw* is practical for me.

Ok, thats fine with me, as I said before it's yours to decide. ;)

Cheers, Markus

> 
> Cheers,
> Peter
> 
>