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
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
