[CMake] cmake for cygwin

Michael Wild themiwi at gmail.com
Wed Oct 27 07:37:16 EDT 2010


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.

> 
>> 
>> We could emit that warning when cmake is run on cygwin for
>> all projects until they require a new enough CMake that
>> contains these changes by using the policy mechanism.
>> 
>> I would like to proceed by using the standard cmake policy
>> mechanism. However, you have made it clear you will not be
>> happy with that approach.
>> 
>> I am curious what you mean by "will need to ship a patched
>> version until this issue is rectified."?  Will you
>> block me from being the CMake maintainer for cygwin
>> somehow?
> 
> This is something we would like to avoid, as the fallout 
> will damage both the communities (cmake and cygwin).
> Think of it as our last desperate solution (nuclear one).

To be completely frank, the commandeering tone you two guys used here already created some fallout, at least on my side. I'll make sure to steer clear of any Cygwin involvement...

> 
>> Sorry this is becoming so difficult.  I seriously just
>> care about the existing CMake users and don't want to break
>> things for them.
>> 
>> -Bill
> 
> Same for us. 
> Cygwin users "usually" expect cygwin tools to 
> build cygwin programs, not strange hybrid.

ACK, but that really isn't CMake's fault (as explained above). It might be true, that not defining WIN32 would fix a lot of packages, but that still means they are broken and should be fixed. I'm convinced that you are trying to fix the wrong software.

Michael

--
There is always a well-known solution to every human problem -- neat, plausible, and wrong.
H. L. Mencken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101027/df1a38a2/attachment-0001.pgp>


More information about the CMake mailing list