On Wed, 15 Aug 2001, Ruslan Ermilov wrote:

> On Wed, Aug 15, 2001 at 12:40:19PM +1000, Bruce Evans wrote:
> > I agree (except the build-tools concept is a hack to work around
> > build-tools binaries not being buildable and installable in the usual
> > way (with 1 binary per Makefile)).
> >
> It seems pretty easy to add src/tools/build-tools/, and move all the
> build-tools there.  What do you say?

Ugh :-).  You would also need messes like src/tools/build-tools/gnu (or
is it src/gnu/tools/build-tools? :-) for cc/cc_tools.  Then when plain
"make all" is run in in a program directory, it would have to reach out
to build tools in far-flung source and/or object directories.

I was thinking of just having file/tools and sh/tools, etc.  Note that
there is already cc/cc_tools, but it doesn't completely solve the cross-
building problems.  Some infrastructure is missing (a place to install
the tools and a way to skip tools directories only when cross-building),
and there are some complications with source files built using the tools
(these should not be built in the same object directory as the tools).

> [...]
> > See sh/Makefile for other tweaks (depend on .o instead of .c ...).  Other
> > probems with this (generally shared with all build-tools binaries):
> > - CFLAGS for the main binary may be inappropriate for the tools
> > - missing dependencies on headers.
> >
> Dependency of a build-tool on .o instead of .c is bad if:
> 1)  build-tools are built in the same ${.OBJDIR} as the main ${PROG}
>     (this is always true)
> 2)  objects for a build-tool are created for the host arch
> 3)  objects for a ${PROG} are created for a different arch
> 4)  ${PROG} and build-tool share one or more object files
> This is not the case for bin/sh, but it's true for usr.bin/file.

Only (4) is crucial.  It can be worked around by renaming some
object files.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to