This is the mail archive of the cygwin@cygwin.com 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: Toplevel configury of src


For what it's worth, I've been working to get the base packages of a
linux-from-scratch system (that being defined as enough stuff to chroot
into a partition containing only those packages and bootstrap a full
system) changed over to meet some similar goals:

	1) Must be able to autoreconf with a single suite of automake,
		autoconf, gettext, libtool, etc ( current versions are all the
		latest alphas I could find at project start, autoconf=2.53a,
		automake=1.6.2, gettext 0.11.1, texinfo=4.2, libtool=1.4.2 )
		
	2) As much as possible share the *.m4 files between all packages,
		replacing package specific modules with generic ones, if such
		modules have appeared since the publication of the packages.
		
	3)	Eventually share the common files like those used for AC_LIBOBJ,
		and compile such functions into a single package which can be
		installed independantly in advance.
		
	4)	Eventually automakify those basic packages which are not so
		built.
		
	5)	Eventually find and factor out (license permitting) or find
		replacements for other common code into the common library, as
		the start of a LGPL'd xplatform portability kit.
		
	6)	Provide some few enhancements to the autotools, in order to make
		their interfaces more uniform, their implementations more
		consistent, and work in the metaconf (not to be confused with an
		earlier tool of the same name, of which I was unaware) project I
		did a few years ago to do for automake what autom4te did for
		autoconf ( use m4/traces to parse m4)

I've got a sourceforge project for this, but have not yet gotten to the
point of uploading my first attempts.  The one thing I have avoided,
since I was aware of the autoconfiscation of GCC, and since I'm no
braver than angels, was to work these changes back into binutils, or
into gcc-2.95, the compiler (for now) of this project.  When and if I am
able to bring the first step to fruition, and to bootstrap a full live
system, including X, I will return to the gcc/binutils issue.
Hopefully, the autoconfiscation will be complete by then, and I will
consider doing something with gcc-3.1.

One of my early tests will be against cygwin, as there are few platforms
so bizarre.  <G>

Eventually, I'd like to "collect the whole set" under this banner, and if
I'm lucky the individual maintainers will find the changes
non-destructive enough to adopt them into their trees.

Make of it what you will.

On Wed, Jul 10, 2002 at 11:26:29AM -0400, Charles Wilson wrote:
> 
> 
> Nicholas Wourms wrote:
> 
> 
> > Perhaps switching everthing over to
> > Autoconf-2.53/Automake-1.6.2/Libtool-1.4e compatible versions might help?
> 
> Going where angels fear to tread, Nicholas?
> 
> The gcc people will switch to autoconf-2.5x and automake-1.6.x when they 
> are ready -- and not a moment before.  And I seriously doubt they will 
> use a cvs release of libtool.
> 
> Besides, even if they did, it wouldn't fix the problems observed.
> 
> --Chuck
> 
> 
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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