[CMake] cmake for cygwin

[Marco Atzeri]

--- 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.

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.

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.


Regards
Marco

Disclaimer: I am just a volunteer cygwin package maintainer, 
my job is totally unrelated to this activity.