Toplevel configury of src

Toplevel configury of src

[Nathanael Nerode]

The toplevel configury of src is, as all you developers know, a mess.
I've been trying to clean it up over at gcc.  I ran into a bizarre
situation and was told that Cygwin people might be able to help clear it
up.

Suppose you're building a combined tree of some sort with target
*-*-cygwin*
powerpc*-*-winnt*
powerpc*-*-pe*
ppc*-*-pe

According to the comments, newlib is 'always' built.  This is false.

If --without-newlib was specified and host=target, the newlib in the
tree is not built.

If --without-newlib is specified and host!=target, the newlib in the
tree is built, but it isn't used; --with-newlib isn't passed to
subconfigures, and nothing is added to FLAGS_FOR_TARGET for newlib.

This is almost certainly wrong behavior.

How should --without-newlib behave when targeting *-*-cygwin* (and the
others)?

Should it mean "Don't build or use the newlib in the tree; use installed
libs and headers, or the ones specified with --with-libs and
--with-headers"?

Should it be illegal, and give an error message?

Should it be unspecified, in which case I can change its behavior for
code cleanliness?

Please send responses to neroden@gcc.gnu.org.  Thanks.
--Nathanael

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

Re: Toplevel configury of src

[Robert Collins]

----- Original Message -----
From: "Nathanael Nerode" <neroden@doctormoo.dyndns.org>
To: <cygwin@cygwin.com>
Sent: Wednesday, July 10, 2002 4:33 AM

> How should --without-newlib behave when targeting *-*-cygwin* (and the
> others)?

I can't speak for the others. Cygwin1.dll -requires- newlib to be built. The
installed c library on a cygwin system is not able to be used when linking
cygwin1.dll.

> Should it mean "Don't build or use the newlib in the tree; use installed
> libs and headers, or the ones specified with --with-libs and
> --with-headers"?
>
> Should it be illegal, and give an error message?

Chris is probably the person with the canonical answer. However, "illegal
and an error", or "illegal, warn, and build newlib anyway" both make sense
to me.

Rob


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

Re: Toplevel configury of src

[Nicholas Wourms]

--- Nathanael Nerode <neroden@doctormoo.dyndns.org> wrote:
> The toplevel configury of src is, as all you developers know, a mess.
> I've been trying to clean it up over at gcc.  I ran into a bizarre
> situation and was told that Cygwin people might be able to help clear it
> up.
> 
> Suppose you're building a combined tree of some sort with target
> *-*-cygwin*
> powerpc*-*-winnt*
> powerpc*-*-pe*
> ppc*-*-pe
> 
> According to the comments, newlib is 'always' built.  This is false.
> 
> If --without-newlib was specified and host=target, the newlib in the
> tree is not built.
> 
> If --without-newlib is specified and host!=target, the newlib in the
> tree is built, but it isn't used; --with-newlib isn't passed to
> subconfigures, and nothing is added to FLAGS_FOR_TARGET for newlib.
> 
> This is almost certainly wrong behavior.
> 
> How should --without-newlib behave when targeting *-*-cygwin* (and the
> others)?
> 
> Should it mean "Don't build or use the newlib in the tree; use installed
> libs and headers, or the ones specified with --with-libs and
> --with-headers"?
> 
> Should it be illegal, and give an error message?
> 
> Should it be unspecified, in which case I can change its behavior for
> code cleanliness?
> 
> Please send responses to neroden@gcc.gnu.org.  Thanks.
Hmm,

Perhaps switching everthing over to
Autoconf-2.53/Automake-1.6.2/Libtool-1.4e compatible versions might help?

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

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

Re: Toplevel configury of src

[Charles Wilson]

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/

Re: Toplevel configury of src

[linguist]

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/

Re: Toplevel configury of src

[Christopher Faylor]

On Wed, Jul 10, 2002 at 09:33:42AM +1000, Robert Collins wrote:
>> Should it mean "Don't build or use the newlib in the tree; use installed
>> libs and headers, or the ones specified with --with-libs and
>> --with-headers"?
>>
>> Should it be illegal, and give an error message?
>
>Chris is probably the person with the canonical answer. However, "illegal
>and an error", or "illegal, warn, and build newlib anyway" both make sense
>to me.

I answered this in the gcc mailing list, but I agree with Robert.  Either
of the above is fine.

cgf

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