Mail Archives: cygwin/2003/11/07/14:17:29
> 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/
- Raw text -