On Tuesday 09 September 2008 12:20:54 Chris Sutcliffe wrote:
> > But, I don't see the issue if the "upstream" runtime library
> > package/src is called mingwrt, but cygwin continues to package it
> > as mingw-runtime. It's no skin off MinGW's back, right? It's
> > just whether Chris wants to avoid transition issues on cygwin, or
> > not. It's up to him, and nobody else. He *asked* for preferences
> > on the cygwin list, and *chose* to accommodate them.
> One of the biggest issues as I understand it from CGF is that the
> new naming standard we switched to would cause problems for
> Cygwin's setup. It wasn't too big a deal to maintain the 2 naming
> conventions, just some minor modification to Makefile.in, this way
> everyone is accomodated.
If the Cygwin maintainers prefer to preserve the previous naming
convention, to facilitate their own builds or distributions, then I
don't have any problem with that; given that they are kind enough to
host our CVS, and particularly in the case of w32api, to make fairly
significant contributions to the code base, I am more than happy to
accommodate their preferences.
However, where I do have a problem at present, is in the manner of
implementation, to accommodate those preferences. Fundamentally, if
I wish to build mingwrt stand alone, I would issue the commands:--
$ ~/cvswork/mingwrt/configure --build=unknown --host=mingw32
$ make dist
and I would expect to obtain correctly packaged tarballs, for native
deployment on a mingw32 host. Currently, this doesn't happen; ergo,
the build system is broken.
When I look in Makefile.in, I see it is littered with heuristic
conditionals, relating to target_alias, which is utterly meaningless
in this build context, for there is no make goal to which any valid
target specification could possibly apply, (therefore there is no
target specification which can be considered to be valid).
IMO, *none* of those conditionals belong in Makefile at all; I'm not
even convinced that they belong in configure, although if necessary
they *could* be controlled by --enable configure options, (with the
defaults being the MinGW preferences, and the appropriate Cygwin
preferences activated by options passed down from a parent Makefile
or configure script, in the context of a Cygwin build).
Our Makefile should simply, and unconditionally define:--
PACKAGE = @PACKAGE_TARNAME@
VERSION = @PACKAGE_VERSION@
mandir = @mandir@
etc. Our configure script should set appropriate defaults for MinGW,
and during a Cygwin build, these should simply be overridden in the
recursive make invocation from the parent, or in the subsidiary
configure invocation; similarly, all installation paths should be
established using the standard provisions of configure. ALL of the
heuristic conditionals, references to target_alias, (and to the
unexplained, and seemingly inexplicable with_cross_host), and the
convoluted install path settings need to go away.
This is something I would like to see fixed, by the time we come to
release mingwrt-3.16. I'm willing to work on it myself, in a couple
of months time. I'm also willing to participate in whatever effort
is necessary, to ensure that we continue to meet Cygwin expectations,
provided the Cygwin maintainers give me appropriate guidance, so that
I may understand what those are.