[RFC] external compiler support

Brooks Davis brooks at freebsd.org
Wed Feb 27 22:05:22 UTC 2013


On Wed, Feb 27, 2013 at 12:28:22PM -0800, Simon J. Gerraty wrote:
> 
> On Wed, 27 Feb 2013 13:58:07 -0600, Brooks Davis writes:
> >Adding the equivalent of Warner's ${__X} (however you spell it) doesn't
> >seem to hurt anything, but it doesn't seem to help much either.  You
> 
> The advantage of Warner's approach is that it can work from anywhere in
> the tree rather than only from top-level.
> 
> One of my goals is that I should be able to [cross-]build bin/cat just
> as easily from src/bin/cat as from top-level.
> Warner's approach fits better in that regard.
> 
> There is of course a lot more needed.
> Being able to add machine and even target specific flags for example.
> These can be just as easily dealt with in share/mk:
> 
> # add machine/taget flags in order of least to most specific
> CFLAGS+= ${CFLAGS.${MACHINE}} \
> 	 ${CFLAGS.${.TARGET:T:R}} \
> 	 ${CFLAGS.${.TARGET:T}}
> 
> etc.  I also find it handy to have 
> 
> CFLAGS_LAST+= ${CFLAGS_LAST.${MACHINE}} \
>          ${CFLAGS_LAST.${.TARGET:T:R}} \
>          ${CFLAGS_LAST.${.TARGET:T}}
> 
> and add ${CFLAGS_LAST} to CFLAGS after Makefile has been read
> so for example when you don't have proper sysroot support you can add
> the equivalent of -I/tree/of/headers/include to the end of the -I list.

I like the end goal, but it doesn't feel like taking this route gets me
any less code in Makefile.inc1 in the short term.

I don't like that for now it forces me to use traditional names for
all these tools (they must match the name of the native tools) and to
install them next to each other (or create a link farm to do that).
This seems to make it unnecessarily difficult to perform any kind of
casual compiler testing across the whole tree.

> >This appears to work:
> >
> >--sysroot /tree/of/headers/and/libraries -B/path/to/binutils
> >
> >For the whole tree to build it must be part of the value of CC.
> 
> No, they just need to be part of the compiler command line.
> 
> >Otherwise /rescue fails as do several things in /boot.
> 
> That would presumably be bugs in the relevant makefiles no?

The problem in both cases is that they need tight control of C(XX)FLAGS
in order to generate small or static binaries.  There are any number
of ways to work around this, but nothing seems very clean.  One could
introduce yet another ???FLAGS variable that they use explicitly as part
of their CFLAGS.  Alternatively, one could change them to aggressively
filter CFLAGS rather than replacing it.

Making the options part of CC works today and avoids needing to modify
many makefiles whose products I can't test easily or in many cases at
all.  Notionally I feel it's equivalent to creating a wrapper script
around each tool to change a couple defaults without the overhead or
hassle.

While I could test the /rescue case, fixing it involves modifying
cruchgen and my first attempt to look at it lead me to run away quickly. :)

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130227/741fc954/attachment.sig>


More information about the freebsd-arch mailing list