Re: [PATCH] Don't build libzgcj all the time

[Phil Edwards <pedwards at disaster dot jaj dot com>]

A message on the gcc list reminded me that I'd never followed up on this...


On Fri, Nov 03, 2000 at 09:33:04PM -0500, DJ Delorie wrote:
> 
> Perhaps we need a mechanism for adding target libraries, but
> traditionally we build whatever's there.  Can you generalize this new
> method a little?  Perhaps using a TARGET_ADDED_LIBS variable (or
> something), which various cases can append to before the master target
> list is generated?  What I'm most concerned about is adding something
> specific to your case; I'd rather add something generic, and let the
> first use of it be your case.  Knowhatimean?

Absolutely.  The general case I had in mind was an n-by-n dependancy
matrix of "possible things we build" versus "things that they need".
The Java compiler and libz, the C++ compiler and libstdc++, etc.

Maybe use the noconfigdirs method and the same matrix to deconfigure things;
not enabling c++ should result in libstdc++ being deconfigured, for example
(right now it isn't).

That would be a pain to do inside a configure script, though; 2D-like arrays
in portable Bourne shell sounds like an obscure form of programmer torture.


> > I'm wishing for a better dependancies selection during configuration.
> 
> Yes, but the fundamental problem is this: How do you know a module
> shouldn't be built just because the user checked it out?  Maybe the
> user wants a target zlib for some target software they're working on,
> and they just happen to be using the one gcc already builds for them?

True, but I think zlib is an exception, not the rule; we usually don't
find general-purpose libraries in the source tree.  I don't think your
statement would hold true for any of the other libraries that we build.
(Although if people out there are using libstdc++ for something and "just
happen" to be using ours, I'd love to see their program!  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.