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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
