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

[Brandon Van Every]

On 10/23/07, Gonzalo Garramuño <ggarra at advancedsl.com.ar> wrote:
> > 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.

Cygwin GCC does not link against the Microsoft runtime, it links
against cygwin1.dll.  Unless you go through a lot of pain to use
-mno_cygwin, which almost nobody uses in practice and is going to
break lotsa things in practice.

> Also, cmake2.5 provides, currently, a "MinGW Generator" AND an "MSYS
> Generator" which could operate differently and have different default
> install locations.

I suggest that you go argue this with the MSYS developers.  If they
tell you what we've told you, then you'll understand why we're doing
what they want, even if you don't agree with it.  If they tell you
they actually think installing stuff to /usr/local by default is a
good idea, then we'll have to reconsider our understanding of their
intent.

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

I sympathize.  I'm not sure how I'm going to get Microsoft DirectX SDK
support out of MinGW though.  Last time I looked at that, the hacks
people had tried were ugly and didn't work.  One possibility is to go
the OpenGL route, which is indeed a more logical cross-platform fit to
CMake capabilities.  But my point is, some people end up in support
scenarios where MSVC is pretty much what they're stuck with.  That's
how Microsoft makes money.

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

I think it has limits on optimization and maybe stack size.  For
instance, it couldn't handle the pile of functions that the Chicken
Scheme --> C compiler generated.  It was enough of a PITA that nobody
ever made a serious effort to solve the problem.

> Some old Unix guru (whoever came up with the idea) provides, in
> practice, the idea of using /usr/local as a sandbox for software.

As I said privately though, that's Unix development, not native
Windows development.  Native Windows development has limitations, as
do all operating systems, but it is what it is.  The core issue is
that you think MSYS should be about native Unix development, and the
MSYS people don't.

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

The rest of us just set our tool paths to be exactly what we want.  We
compile from CVS to the degree that it is actually important to us.
Clearly, it is not so important to you, or you would have a
hermetically sealed build environment that does it already.

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

But the choice of %ProgramFiles% or /usr/local doesn't change any of
this.  There are always lotsa build scenarios, and they're all going
to have different bugs.  If you're too overloaded to deal with them,
then you're too overloaded to deal with them.  You can try to marshal
other people to deal with them, and they either will or won't.  If
nobody will deal with them, then they don't get dealt with.  In Open
Source you get what you pay for.

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

You can certainly make it true for fltk2.

> Same thing will happen for any autotools project
> that works under msys that wants to move to cmake.

That doesn't follow.  The autotools crowd is stuck with MSYS and
Cygwin shells.  CMake isn't.  It's a political battle, between people
who think cross-platform == Unix and people who think cross-platform
== doing things the way the native system does it.  When migrating a
project from Unix to true cross-platform development, there's
inevitably politics to reckon with.

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

My political experience is that you should not make it easy for the
Unix guys to continue with business-as-usual.  If you do, they will.
They will drop CMake like a hot potato the minute they have to do real
work to support MSVC.  If you're going to work as an open source
volunteer, only work with projects that *know* why they need real
cross-platform support, and are ready to do what it takes to implement
it.  Including harshly jettisoning "old ways" of doing things.  Either
that or get paid for your efforts, so that you have something when
they abandon your work.

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

People who don't want to move on use Cygwin.

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

You could have read the e-mail archives.  :-)  And you can still read
MSYS's e-mail archives.


Cheers,
Brandon Van Every