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
Date: Fri, 7 Nov 2003 11:14:52 -0800
From: "Edward S. Peschko" <esp5 AT pge DOT com>
To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Cc: cygwin AT cygwin DOT com
Subject: Re: cygwin patches integrating back into standard gnu
Message-ID: <20031107191452.GB16244@mdssdev05.comp.pge.com>
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> <3FAB099D DOT 9090705 AT cwilson DOT fastmail DOT fm>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FAB099D.9090705@cwilson.fastmail.fm>
User-Agent: Mutt/1.4.1i

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

that's just silly. Gnu builds are uniformly prefix-friendly, and there
was a simple way to 'make a development environment' for any given platform,
then you could have your autoconf-2.13 (old) environment, and your autoconf-2.5
(new) environment based on path. And you would hack on one or the other 
based on what environment you were in. It'd probably be easier to 
port between the two, too.

Which - I might add, cygwin does *not* lend itself to given that each
build.sh script that I saw had hard-coded paths in it for building 
to /usr/bin, non-standard steps for install, etc. 

If it built clean in whatever prefix you desired, you could do a 
little substitution trick, to get binary builds for *any* path:

    1) substitute (in binary files) any prefix with a different 
       prefix, and pad it with null characters ('/tmp/very/long/prefix' 
       becomes '/my/prefix...........' where . is \0)

    2) substitute (in text files) any prefix with a different prefix
       minus the null padding.

and hence have more than one cygwin environment per cygwin.dll. 
It'd probably be wise to integrate this with setup.exe so you would 
have the option to install packages in a non-standard place. 

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

Ok, one question... If I'm going to temporarily maintain these patches, it
sounds like I'm going to need to only apply them with cygwin builds, right?
And that they may not fit with older gnu builds?


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

well, its nice to see that there are formal mechanisms, but the method 
for doing this (two environments based on multiple paths) has been around
for a while..

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

I think you misunderstand me. You would:

    a) have a centralized account, call it 'cygwin-gnu-patches' or somesuch. 
    
    b) There would be a maintainer for that account, who would be 
       a go-between that doesn't have an agenda in accepting or 
       rejecting patches, but is more of a spam-filter. Sort of a 
       'patch pumpkin' to accept perl5's terminology, but whose only 
       goal is to make sure the patches are in acceptable form before 
       sending them off to the right destination.
    
    c) There would be a matrix of mailing lists based per package, cygwin
       maintainers per package, a cross-reference that tells which patch goes where. 
       There would be a database which shows the status of each patch (whether its at
       maintainer submission stage, maintainer acceptance stage, gnu submission stage,
       gnu acceptance stage)
       
    d) Users would compose a description for the patch, as well 
       as the patch itself and send it to this mailing list. 

    e) a mechanism for showing acceptance of the patch would be given to 
       to both cygwin or gnu (or other mailing list) maintainers so 
       that you could track the status of the patches' submission.

    f) any discussion on the patch would include a CC of the maintainer's email 
       address.

So its not a 'dumb patch-spammer'; its a 'grand central station' for patch
submission (and it probably would have utility outside of cygwin). 

It more directly fits my needs, as someone who casually works with 
environments, finds things that I need, don't like, or want to add, yet
don't want to go through the extra work of subscribing to lots 
of lists and find it easier to maintain my own patches instead. I doubt
I'm the only one who fits this category.

Ed

--
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/