On 10/24/2010 11:52 PM, Yaakov (Cygwin/X) wrote:
On Fri, 2010-10-22 at 13:12 +0000, Rolf Eike Beer wrote:
So this is only different from what other build tools or whatever do. But
it is well known behaviour, it is documented, and it can't be changed for
backward compatibility anyway.
The only platform which this affects is Cygwin, we (the Cygwin package
maintainers) regard this as a bug, and therefore are not concerned with
backward compatibility.
Let me make this clear: with WIN32 defined, CMake is practically
*useless* to us on Cygwin, as it requires patching almost every
CMake-based package to build correctly. With WIN32 undefined, almost
all packages build OOTB. Simple as that. Shouldn't we -- the users and
distributors of Cygwin -- have the final say as to how Cygwin should be
handled?
The problem is Cygwin has changed over time (IMO). In the beginning
when CMake started to support Cygwin we used as a way to build win32
applications with a free compiler. The charter for cygwin seems to have
changed over the years to be a linux/unix system on top of windows where
the default is to build X11 API applications. For the past decade, the
majority of VTK users of cygwin used the win32 api when using cygwin and
not X11.
However, I can see the point of wanting unix/linux applications to build
out of the box on cygwin with no changes. Not sure I agree with using
X11 on windows, but hey it is the quickest way to get an application
running.
At the end of the day, CMake should be following the majority of the
cygwin applications. However, I really don't want to break the code of
the people that have spent the time to get applications working on
cygwin with CMake over the past 10 years. That is what would happen if
we suddenly changed CMake without warning. The only applications that
would break are the ones where people actually made an effort to port to
cygwin using CMake.
So, I think the only way to fix this is to create a new policy. The
policy will warn all cygwin builds that CMake is no longer defining
WIN32 on cygwin. As with all policies, if a project has the minimum
required CMake set to the version of CMake that implements the policy
the new behavior will happen. I know this will not make Yaakov totally
happy as CMake based applications will not work unless they bump up the
version of CMake they require, but over time all will be well. The only
other option that might make the cygwin X11 crowd happier would be to
add a --cygwin-mode that forced the policy to be NEW, and would provide
an easy way for Yaakov to port applications without having to change the
source of the application being ported.
Some info on policies:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Policies
-Bill
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
