This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Re: A clue for the libstdc++ problem.
On Sun, Apr 01, 2001 at 08:35:45PM -0400, Phil Edwards wrote:
>
> At once point we threw around an idea of a set of "binaries" in
> $builddir/$target/bin which would know how to find headers and libraries in
> $builddir/$target/lib*. The correct-compiler problem for other libraries
> and programs would be reduced to simply calling "../bin/g++" from their
> top-level dir. (Or ../bin/gcc, ../bin/xgcc, ../bin/whatever-you-want.)
>
> The "binary" would be a simple tool to accumulate all the needed options
> and then exec the proper $builddir compiler; whether it's a real binary or
> a shell script, and how much of libstdc++-v3/tests_flags.in it would use,
> was still open to question. (As well as "is it worth the extra runtime
> overhead and complexity," etc.)
>
> It's been on my todo list, but never took priority over the other stuff I
> was fooling with. Is this a viable concept? Most of the other stuff is
> about finished; I could devote some time to hack on this if the Hivemind --
> ah, that'd be all of /you/ -- deems it useful.
It seems to me that the present problem is not so complicated that it
needs a hammer this big. But it might be worthwhile to use a hammer
this big for other reasons - e.g. if it can substantially reduce the
complexity and fragility of the top level driver logic, that would be
worth it.
I guess I'd suggest you breadboard something and see how much of a
difference it makes.
zw