This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin patches integrating back into standard gnu
Edward S. Peschko wrote:
I was curious - exactly what is the process to submit cygwin patches to the respective
projects that support cygwin as a target?
I've been integrating cygwin into the build for the OSes I support, and I find that there
are hundreds of thousands of lines of patches for cygwin (around 400k). Some are
trivial, some are fairly substantial (ex: popt's patch is approx 1/3 the size of the
Most "upstream" maintainers will accept modest patches to help support
the cygwin platform. By and large, the packages with huge packages are
simply autoconf-generated stuff.
See, to build a shared lib, you really really need to use libtool-devel,
which is libtool-1.5, and which requires automake > 1.5.0 and autoconf >
2.50. However, those packages are just now -- after 1.5 years -- coming
into widespread use, because
1) autoconf 2.5x is in some ways incompatible with autoconf-2.13 --
which means that an upstream package maintainer has to decide "Okay,
everybody who hacks on my package now must install autoconf-2.5x on
their system." But then each developer also must make a decision --
"Hmm. I can only install autoconf-2.13 OR 2.5x but not both. These 5
packages I like to hack on require 2.13. Those 2 require 2.5x. Shall I
switch to ac-2.5x and stop hacking on the 5 old packages?"
So that's why many (upstream) maintainers have been loathe to 'make
the switch' -- and why some of our patches are large. A two-line change
to configure.in may lead to many thousands of changes in configure after
re-autoconfing with 2.5x.
2) Now, multiply that by automake-1.4p5 vs automake-1.7.5, and
libtool.m4/ltmain.sh from libtool-1.5 vs. libtool.m4/ltconfig/ltmain.sh
3) Things are slowly getting better. Some platforms are now finally
providing mechanisms where both autoconf-2.13 and autoconf-2.5x can
coexist. (Cygwin has been doing this for years, but Red Hat et al took
a little longer) Plus, every week that goes by, another upstream
maintainer "takes the plunge" -- opening the way for our patches to go
back. This trend is now (finally) accelerating.
I'm loathe to have to support these patches, esepcially because some seem
to be cross-platform unfriendly,
Okay. Most (all?) of mine are cross-platform-friendly, but after all,
cygwin maintainers are maintaining **cygwin** ports -- so you can hardly
blame them for not doing *extra* work.
so I was hoping that some sort of concerted effort
is being made or could be made to make the ported cygwin packages 'build clean from the
box', so that ./configure --prefix=<..>; make; make install would work for 99% of them
AFAIK, every cygwin maintainer has the goal of pushing patches back
upstream. However, some upstream maintainers are more resistant than
To that end, I've put together - attached to this message - a small perl script that
goes off, fetches all of the latest cygwin project source code, and extracts all the
patches and README files from the tarred packages.. It saves the source files in
'./build', and the patches in './patches' It should run as-is under cygwin, but if it
doesn't I wouldn't mind putting together a small PAR file to make it self-contained.
Anyways, I could (or someone could) modify it so that, as an option, the patches
within are sent to the appropriate mailing list for inclusion. I would think that such a
matrix would be helpful in general, as well as a centralized user which could be a
conduit for submitting patches to the right place. (which to me is a lot better idea
than everyone using the script to send the same patch over and over) But 400k of patches
seems just a bit high.
Oh god no. Automated patch-spam to mailing lists? I can't think of a
better way to ensure that our patches are rejected.
The Right Way To Do This is for each (cygwin) maintainer to handle it --
after all, they are the most informed on the subject. Plus, in many
cases you don't WANT to send all 400k of patches:
1) most (upstream) maintainers want small, easily digestible patches
-- so mega-patches must be split up into functional units.
2) the autotool-generated portion of each patch shouldn't go back;
only the changes to the source files (configure.in, Makefile.am) with
the note that "This assumes you reautoconf with autoconf-2.5x or higher,
re-automake with automake-1.7.5 or higher, re-libtoolize with
libtool-1.5 or higher." etc.
A dumb patch-spammer is NOT the way to go, here.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html