[CMake] cmake for cygwin

[Alexander Neundorf]

On Wednesday 27 October 2010, Michael Wild wrote:
> On 27. Oct, 2010, at 12:38 , Marco Atzeri wrote:
> > --- Mer 27/10/10, Bill Hoffman  ha scritto:
> >> On 10/26/2010 9:58 PM, Yaakov
> >>
> >> (Cygwin/X) wrote:
> >>> On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman
> >>
> >> wrote:
> >>>> Backwards compatibility may not be important to
> >>
> >> you, but to CMake it is
> >>
> >>>> very important.  When a developer chooses to
> >>
> >> use CMake, I want to
> >>
> >>>> respect that choice, and work as hard as I can to
> >>
> >> make sure I don't
> >>
> >>>> break that code.   CMake has been
> >>
> >> doing this for 10 years on cygwin,
> >>
> >>>> wrong or right that is how it has been
> >>
> >> done.   If there is code that
> >>
> >>>> builds with CMake on cygwin today, your suggested
> >>
> >> change will break that
> >>
> >>>> build.
> >>>
> >>> No, it will most likely *fix* it.
> >>
> >> How is that possible?  If it is working today with the
> >> way CMake is for someone, and we make this change, it will
> >> stop working.  It can not *fix* something that is
> >> already working.  It can only break something that is
> >> already working, it can not fix something not broken...
> >
> > Bill, it is not working. We don't succeed to port
> > programs using cmake as build chain in the cygwin distro,
> > using your package. I need to use Yaakov one.
> > So I need a working alternative.
>
> The ones you tried to port didn't work, but there are the ones that work as
> they should (as has been reported in this thread). The proposed change
> would potentially break them. This is bad. Really bad. Breaking working
> builds in order to fix broken ones is just plain wrong.
>
> > I doubt any linux distribution will accept to release
> > a key tool that doesn't follow the distri guideline.
>
> That's preposterous! This is not a guideline, this is hijacking the
> project! Whether WIN32 and CYGWIN are defined simultaneously or not is a
> matter of convention and as far as Cygwin is concerned it is an
> implementation detail. It might have been a bad choice, granted, but that's
> all there is to it.
>
> Clearly it is possible to create a working build system for Cygwin with the
> current implementation, so it is NOT CMake's fault if people create broken
> build systems. You should report it to the respective package maintainers
> and tell them to fix their build systems, otherwise you don't accept their
> packages into Cygwin. That would be the proper (although for you more
> tedious) solution. They are breaking guidelines, not CMake. Period.
>
> >>> Bottom line: we insist that the CMake in the Cygwin
> >>
> >> distro not define
> >>
> >>> WIN32.  If you're prepared to handle that
> >>
> >> upstream now, great.  If not,
> >>
> >>> we will need to ship a patched version until this
> >>
> >> issue is rectified.
> >>
> >>> How do you wish to proceed?
> >>
> >> I guess you could release a patched cygwin that defaults to
> >> having the policy set to new, and I could release one that
> >> has the policy set to warn by default.
> >>
> >> 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