This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cmake update needed
- From: "Tony Kelman" <tony at kelman dot net>
- To: <cygwin-apps at cygwin dot com>
- Date: Thu, 5 Feb 2015 21:41:15 -0800
- Subject: Re: cmake update needed
- Authentication-results: sourceware.org; auth=none
- References: <54D1F25E dot 20701 at gmail dot com> <BAY169-DS1438076617CAC9B60DFC2CA73A0 at phx dot gbl> <1423093749 dot 596 dot 11 dot camel at cygwin dot com> <BAY169-DS20D64B9DEEF05161FF6EEFA73B0 at phx dot gbl> <1423107612 dot 596 dot 24 dot camel at cygwin dot com> <BAY169-DS2928D017F1DAC36EBB51CA73B0 at phx dot gbl> <1423133897 dot 596 dot 29 dot camel at cygwin dot com>
Do you have any specific questions?
2.8.9-perl-libs.patch AIUI changes PERL_POSSIBLE_LIBRARY_NAMES from
being set to "perl{PERL_VERSION_STRING} perl" only when the command
`${PERL_EXECUTABLE} -V:libperl` fails, to appending those values any
time PERL_EXECUTABLE is found. Is that command expected to fail in some
circumstances where one would be building a perl library? Or is the
problem that cmake find_library has trouble with the cyg* library prefix?
2.8.12-gui-qt4, 2.8.12-opengl, 2.8.12-ruby, and 2.8.12-tclsh look pretty
straightforward and worth upstreaming. Should I assume you have not yet
tried to do so?
#-cygwin.patch, which I had to rebase a few times to apply to the latest
release, does multiple things (good sign it should have been split into
multiple patches):
First, it disables case-insensitive matching. I see that there are some
non-default/experimental ways of running Cygwin in case sensitive mode,
but that is a runtime configuration. Most users are probably running with
case-insensitive default NTFS. If this change fixes more issues than it
causes I can take your word on it, but this would be hard to convince
upstream about. Is case sensitive matching really the right build-time
behavior to choose for Cygwin's cmake package?
Second, it corrects some /proc/cpuinfo, /proc/meminfo, etc special-casing
of Cygwin where using the same code as Linux should work. Makes sense,
I'll split this out so it can be discussed on its own w/upstream.
Lastly, it's disabling handling of Windows paths, and conversion from
Cygwin paths to Windows paths. It does look like PathCygwinToWin32 could
go away if the only place it's used in FileExists is changed to just use
access(). Upstream might find this and the change to FileIsFullPath
debatable though, since a use case for a decent number of people is
running cmake within Cygwin to drive non-Cygwin compilers. Should we
really ignore this use case?
Thanks,
Tony