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