[CMake] cmake for cygwin

[Marcus D. Hanwell]

On Thu, Oct 28, 2010 at 8:45 AM, Marco Atzeri <marco_atzeri at yahoo.it> wrote:
> --- Mer 27/10/10, Marcus D. Hanwell  ha scritto:
>
>> On Wed, Oct 27, 2010 at 2:38 PM, Alan
>> W. Irwin
>
>> 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
>
> Hi Marcus,
> I guess your comments were for me and not really for Irwin.

Yes, I failed at using the web interface to my email to reply to a
long thread...
>
> Unfortunately in this case the policy chosen for CYGWIN
> is a BAD one, causing most of package not originally designed
> with cygwin in mind (and I should say they are the vast majority)
> to be almost impossible to correctly port on Cygwin
> without a deep and invasive patch activity.
> My and Yaakov's experience is that inverting the policy
> the porting becomes very easy and almost all the package
> build from the source without patches or few very basic
> changes.

It seems that the policy based approach would have allowed you a one
line patch to most packages (changing the policy to NEW). I work with
people who have specifically worked on getting their project to build
in Cygwin, and it sounds like this change would require them to change
their project after CMake is updated. That sounds bad, and is the
whole reason that CMake policies were introduced - to allow CMake to
fix old behavior without breaking packages that rely upon said
behavior (until they are ready to port).
>
> I hope this also clarify you and the others why we are so
> "obsessive" about this change. I prefer this change in
> cmake than starting a "don Quixote" quest to change all the
> softwares that use cmake as build system.
>
I have patched many a build system in my time, and identify with you.
>
> Disclaimer: I am just a volunteer cygwin package maintainer,
> my job is totally unrelated to this activity.
>
All of my packaging experience was voluntary too, and it can be a
thankless task. I just always preferred to work with upstreams as much
as possible when packaging. My comments were more directed at you
coming from someone who has had many years of experience packaging for
a Linux distribution - largely dealing with CMake projects such as
KDE.

Marcus