[CMake] cmake for cygwin

[Marcus D. Hanwell]

On Wed, Oct 27, 2010 at 2:38 PM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> On 2010-10-26 17:53-0400 Bill Hoffman wrote:
>
>> The policy mechanism might not be ideal but in a year or so, all of this
>> would go away, and the meantime the patches you have to maintain for cygwin
>> ports would become trivial.  The patch would basically have a set cmake
>> version at the top.   I thought the command line option was a nice
>> compromise.
>
> Bill, as somebody associated with a software package (PLplot) which
> already works on Cygwin, I think the policy mechanism is the ideal way
> to handle this requested change.  I do believe the Cygwin packagers
> when they say the change will make a lot more projects build without
> issues on Cygwin, but it is also extremely likely their preferred
> solution (breaking backwards compatibility for cmake) would also break
> currently working builds (such as the PLplot one) on Cygwin.
>
> I sympathize with the frustrations of the Cygwin packagers at the
> slowness with which this issue has been dealt with, but OTOH, I am not
> sure they completely understand the neat resolution of the issue that
> you are now offering with a policy-based approach to the requested
> change. Thus, I suggest you just go ahead and implement that preferred
> solution without further frustrating delays. Then publish cookbook
> instructions about the one-line change that needs to be made in the
> top-level CMakeLists.txt file of each currently non-working Cygwin
> project (but not the working ones like PLplot) in order for the new
> policy to be recognized. Ideally, upstream projects that currently
> don't build on Cygwin will adopt this solution, but if they are slow
> in doing that, it should not be too difficult for the Cygwin packagers
> to implement a sed (or whatever) script to do the required one-line
> changes in the top-level CMakeLists.txt files for each package in an
> automatic fashion.

As someone who packaged software for Gentoo Linux for many years I can
sympathize with your frustration when something is not corrected in a
timely fashion. I don't know much about the background of this
particular case, but I would hope that you would choose to work with
Bill rather than patch CMake and circumvent his efforts to fix this
issue.

If this results in a one line patch to Cygwin packages in the short
term, which can be removed in the longer term, that would seem like a
reasonable solution to the problem. Breaking backwards compatibility
could potentially break all of the packages people got working on
Cygwin with CMake, and that would be far worse.

Disclaimer: I am also a Kitware employee, but before I came here I
worked in open source for many years as part of larger projects such
as Gentoo, KDE and Avogadro. I for one like the policy mechanism, as
it allows CMake to move forward while not breaking existing builds. As
a packager I would never intentionally change the default behavior of
a project, effectively forking the project.

If you chose to take such rash action I would also avoid cygwin in the future.

Marcus