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.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
