[CMake] CMake2.5 - wrong default install location for mingw

Tue Oct 23 08:12:12 EDT 2007

Bill Hoffman wrote:
>
> The C++ code did not "forget" anything.  I intentionally do not set 
> the CMAKE_INSTALL_PREFIX to the equivalent of /usr/local in a windows 
> PATH because I think it is the wrong default.  I still think that it 
> is correct to install into program files.  The only case where I would 
> accept /usr/local as the default for make install for msys, is if 
> someone made a native msys version of cmake that linked to the msys 
> run time.  That would be a cmake used for creating other msys 
> applications that would install into /usr/local for msys.  If cmake is 
> creating a native windows application that uses the microsoft run 
> time, then it is a native windows application and it belongs in 
> program files.  Native windows applications do not belong in 
> /usr/local (since they don't even know what /usr/local is).
But mingw or cygwin under windows will ALWAYS link against the microsoft 
runtime, regardless of whether you compile cmake specifically for it or 
not. It isn't likely mingw or cygwin will change that unless they go 
into the OS business.
As such I fail to see the logic then of why you would make it install on 
/usr/local if you were linking against a mingw runtime and not the other 
way.  Either way, you are still linking against one (or more) microsoft 
libraries when on windows. 
Also, cmake2.5 provides, currently, a "MinGW Generator" AND an "MSYS 
Generator" which could operate differently and have different default 
install locations.
I'll ask you a trick question.  How do you know the user IS running 
under windows and using a microsoft runtime?  He could be running it 
under wine and not having a single microsoft DLL in sight.  Do you 
consider wine windows?  The underlying OS is really linux and all the 
wine DLL's link against the linux libraries.  If you ask me, in these 
days of virtualization, choosing install locations based on who is the 
owner of an underlying DLL seems VERY hard to do right and well... wrong 
to me.
>
> Perhaps it would help if you explained your use case.   
Sure, I'll give you several examples.
> Why would you want to build MSVC and an MSYS version of your software 
> on the same machine?  
To follow your advice from some months ago, where you specifically told 
me that you just COULDN'T generate Visual Studio files without linking 
to the Visual Studio library (back then I also disagreed, but since I 
don't know the VS innards well enough, I took your word for it). 
Funny enough, it was kind of the reverse argument of what you are saying 
now.
Up to an earlier cmake2.5 version from 2 or 3 months ago (my stable one 
that got overwritten), that was still true.  A MinGW cmake could not 
generate MSVC projects.  It seems now this may have changed (not sure, 
did not do proper tests yet).
> Do they behave differently?  
Don't know.  They used to.  Do they?
> Or, are you just testing to make sure your stuff can be built by both 
> MSVC and MSYS?
Correct.  I also have code that I need to compile that cannot be 
compiled under MSVC (ffmpeg, for example, due to microsoft's broken 
compiler up to 7.1 at least).  No other proprietary alternative video 
library matches all that an even LGPL ffmpeg can do.
Also, one of my template libraries also started crashing the microsoft 
compiler version I use with an undocumented C1001 and as such I am 
considering banning the compiler completely from all my build projects 
in the future.  I honestly I am not going to be the betatester for 
microsoft for a product that cost me U$1500 and works worse than gcc and 
will now require even more money to upgrade to fix the bugs I need.  Nor 
am I going to upgrade to a free MSVC8 before I ship my product as I 
don't even know all the limitations of Express (which I'm sure there are 
there).
> If they do not behave differently, why would you want one installed in 
> program files and one in /usr/local?
They DID behave differently.
But I also answered this privately to Brandon.  Basically, because 
that's a very good development policy that at least *I* like (but I'm 
pretty sure I'm not alone on this one).
Some old Unix guru (whoever came up with the idea) provides, in 
practice, the idea of using /usr/local as a sandbox for software.  
Autotools makes that the default even.
I can easily get the latest ffmpeg from svn, compile it in /usr/local 
and see if it broke stuff.  LD_LIBRARY_PATH or PATH has /usr/local in it 
first.  If something breaks, I don't upgrade or ship my software with 
that version.  I keep using the one in /usr or in $PROGRAMFILES.
If cmake worked like that on windows, I could do the same thing with 
cmake.  Currently, I can't unless I specifically remember to pass a flag 
each time.  So even though I upgrade cmake from CVS I usually don't 
compile it and try it, and I am now 2-3 months behind cmake development.
I'll give you yet another example.  I contributed 3 or 4 modules to 
cmake.  I got an email asking to become maintainer for them.  If I 
cannot check my code against the latest cmake sanely, I honestly don't 
want to even try to maintain it.  I already support close to 10 open 
source projects and soon two closed source ones.  There's no way I could 
guarantee my modules work correctly with latest cmake.  Or debug those 
modules under MSYS, MSVC and MinGW (I'd have to choose one).
Yet one more example.  I am currently forking fltk2 (at least 
temporarily) with one of the goals to add cmake support, as properly 
keeping in sync VS files is, in my opinion, one thing that is slowing 
fltk2's development. 
Currently, it also builds using autotools under MSYS and as such it 
installs in /usr/local by default.  User's will expect that to keep 
working the same way.  Same thing will happen for any autotools project 
that works under msys that wants to move to cmake.  If each one of them 
needs to keep adding CMAKE_INSTALL_PREFIX and figuring out where msys is 
installed, there will be much less desire to move to cmake due to the 
headache and will likely soon lead to a mess of some CMakeLists.txt in 
each ported autotools project using some custom method to detect where 
msys is while others use another.   Nightmare.

Anyway, that's several examples why I would like cmake to follow 
msys/autotools policy under at least one generator.  The one called 
"MSYS" kind of seemed the more logical one.

P.S.  To be honest, I thought that just changing a default install 
locations was going to be a very simple request.  I cannot believe I've 
now spent 5 or 6 emails defending this position.

-- 
Gonzalo Garramuño
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy