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

[Bill Hoffman]

Gonzalo Garramuño wrote:
> Bill Hoffman wrote:

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

Nothing has changed here, if you build cmake with MinGW, it will not be 
able to create visual studio projects.

>> Do they behave differently?  
> Don't know.  They used to.  Do they?

OK, so in the case of CMake, the MinGW built version is less capable, as 
it has no GUI (there is no MFC with MinGW).   However, in the case of 
CMake, there is no reason to use a MinGW built version of CMake, it 
really is not a supported platform for building CMake with.  I have made 
a nightly binary available for people that want to use CVS CMake and do 
not have the MS compiler.

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

You do realize that you can get the microsoft compiler for about $300, 
the standard version is just fine for C++ development.


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

Actually, you should only have to specify the install directory once, 
and just keep the binary directory around.   Do a cvs update, then do a 
make in the build tree.


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

OK, now this is more what I was asking for.   If autotools based 
projects in msys install into /usr/local by default, then maybe CMake 
ones should as well.  I think I am going to post to the msys mailing 
list and get some input from those folks.   My reason for not wanting to 
use /usr/local was that msys states that it does not want to become a 
cygwin, but rather just a tool so that you can build autotools projects 
under msys.  Basically, they do not want to make it easy to extend msys, 
they want you to use it to build stuff with gcc on windows.   With 
applications, it makes sense to put them in program files, as they are 
native windows applications.  However, with a library and header files, 
the story is a bit different.   If you install a library into 
/usr/local/lib and headers into /usr/local/include then the compiler 
that is going to use them does know about /usr/local, and how to find 
and use files in the POSIX paths.

> 
> 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.
> 
I am starting to change my mind, but am still going to post to the msys 
mailing list.

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

Email, is a poor form of communication for stuff like this.   I am sure 
if we talked on the phone or meet in person this would have been 
resolved much quicker.

I will get back to the list with what I find out on the msys list.


-Bill