Mail Archives: cygwin/2003/11/06/21:58:20
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/
- Raw text -