[CMake] cmake for cygwin

[Marco Atzeri]

--- Mer 27/10/10, Alexander Neundorf ha scritto:


> > >> I suppose one other options is something like
> this:
> > >>
> > >> "Warning: CMake has be forced to break
> backwards
> > >> compatibility by the cygwin ports
> maintainers, we apologize
> > >> if this broke your code. If your code does
> not compile, then
> > >> set the cygwin policy to OLD, or add
> if(CYGWIN) set(WIN32 1)
> > >> to your code."
> > >
> > > I am not familiar with the cmake policy stuff.
> > > But it seems a workable solution.
> >
> > In my, not so humble, opinion it is the only solution
> if you insist on
> > changed behavior.
> 
> I agree too.
> As a cmake developer, keeping backward compatibility is one
> of the major goals 
> of cmake.
> Just changing the behaviour will most probably break stuff
> which is working 
> now.
> Who uses cmake for building for cygwin, can test for 
> if(UNIX)
> or
> if(CYGWIN)
> 
> To differentiate between CYGWIN and a "real" native UNIX he
> can also test for 
> if(WIN32), e.g. to check whether some other Windows stuff
> exists on the 
> system (which does).
> This seems like a good and sensible choice to me.
> 
> If a cmake-based project wants to support cygwin, it must
> be aware of that.
> If a project which was developed on e.g. Linux is ported to
> Cygwin, some 
> patches may be necessary to that program. I think that's
> normal when porting 
> software to another OS.
> 
> Alex

Dear Alex,
thanks for you comments, but I would like to highlight
one missing point on your reasoning.

We don't want to limit ourself to the packages where 
the developer thought of cygwin as a defined target, 
we are potentially interested to all packages that have 
a generic unix as target.

Most of the projects ignore what cygwin is; their developers
write CMakeLists.txt with IF(WIN32) conditions for windows
and IF(UNIX) for unix.

Trying to build such programs on cygwin with both the 
two conditions is doomed to failure. To port such package,
that are by large the majority, on cygwin we have 3 options:

1) 
propose a long patch to every upstream, highlighting the 
mistake they did forgetting us. Considering the easy success 
we have to convince cmake developers, this road is more
a less a nightmare for any cygwin package maintainers.

2) 
use a cmake package outside the cygwin distro that don't set
WIN32 for cygwin. It is my current solution; but it is not
optimal for cygwin  as I would like that also others could 
build the packages as I am doing. 
Should every cygwin maintainer have its own cmake package ?

3)
convince the current cmake cygwin package maintainer, that
is also a cmake developer, that we need a way to unset WIN32.
How ? I am open to proposal, except case 1, please.

I understand that making a unconditional WIN32 switch
could break some package, but I suspect they are much less
than Bill is afraid of. After all I built both CMAKE and VTK
with WIN32=0. But I admit that eventually my build is 
different from the original aim of their developers.

Having a switch/policy to define the cygwin behaviour,
is a possible solution that would allow us to build the majority
of unix package as smooth as possible also for cygwin 
and allow current developers using cmake on cygwin 
to maintain their settings if they need so.

Regards
Marco