This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 regular distribution!)

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 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/ from libtool-1.5 vs. libtool.m4/ltconfig/ from libtool-1.4.3.

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

AFAIK, every cygwin maintainer has the goal of pushing patches back upstream. However, some upstream maintainers are more resistant than others.

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 (, 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: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]