Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3FAB099D.9090705@cwilson.fastmail.fm>
Date: Thu, 06 Nov 2003 21:55:25 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: "Edward S. Peschko" <esp5 AT pge DOT com>, cygwin AT cygwin DOT com
Subject: Re: cygwin patches integrating back into standard gnu
References: <3FAABE0A DOT 6090406 AT ekers DOT idps DOT co DOT uk> <1068154769 DOT 3faabf91a071f AT www DOT nexusmail DOT uwaterloo DOT ca> <20031106222357 DOT GA25195 AT redhat DOT com> <20031107023331 DOT GA16244 AT mdssdev05 DOT comp DOT pge DOT com>
In-Reply-To: <20031107023331.GA16244@mdssdev05.comp.pge.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 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 
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 (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.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/