Re: Cross-objdump, -objcopy, -strip support in Debian tools
Hello Simon,
2010/3/25 Simon Richter <sjr@debian.org>:
> $CC_FOR_BUILD would be the convention from the GNU "toplevel" project.
Apparently that is, but in practice also BUILD_CC is in use (at least
eglibc uses it -- maybe needs fix). I think GNU fails on that
convention, but it is probably the way to go. I am not sure how is
this in BSD world.
Take into account we also have:
AR_FOR_BUILD
AS_FOR_BUILD
CC_FOR_BUILD
CFLAGS_FOR_BUILD
CXXFLAGS_FOR_BUILD
CXX_FOR_BUILD
DLLTOOL_FOR_BUILD
GCJ_FOR_BUILD
GFORTRAN_FOR_BUILD
LDFLAGS_FOR_BUILD
LD_FOR_BUILD
NM_FOR_BUILD
RANLIB_FOR_BUILD
WINDMC_FOR_BUILD
WINDRES_FOR_BUILD
YACC
BISON
M4
LEX
FLEX
MAKEINFO
EXPECT
RUNTEST
AR
AS
DLLTOOL
LD
LIPO
NM
RANLIB
STRIP
WINDRES
WINDMC
OBJCOPY
OBJDUMP
CC_FOR_TARGET
CXX_FOR_TARGET
GCC_FOR_TARGET
GCJ_FOR_TARGET
GFORTRAN_FOR_TARGET
AR_FOR_TARGET
AS_FOR_TARGET
DLLTOOL_FOR_TARGET
LD_FOR_TARGET
LIPO_FOR_TARGET
NM_FOR_TARGET
OBJDUMP_FOR_TARGET
RANLIB_FOR_TARGET
STRIP_FOR_TARGET
WINDRES_FOR_TARGET
WINDMC_FOR_TARGET
RAW_CXX_FOR_TARGET
FLAGS_FOR_TARGET
COMPILER_AS_FOR_TARGET
COMPILER_LD_FOR_TARGET
COMPILER_NM_FOR_TARGET
> If, at some point, we were to decide that we want dpkg-buildpackage to
> set $CC, then it should at the same time also set $CC_FOR_BUILD, so
> "toplevel" based projects (i.e. binutils, gcc, gdb) don't break when we
> override $CC.
>
> Currently, we do neither, and that appears to work as well -- I expect
> projects that build tools but don't use "toplevel" as their project root
> or otherwise follow their convention to break if $CC starts being
> exported.
>
> This is a very small group, nevertheless it would require patches to be
> submitted and incorporated or maintained.
>
> Perhaps we ought to write a policy extension to define how packages
> should react to $CC being set?
Sure, should we start by writing a draft wiki page on the topic?
Kind regards :-)
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
Reply to: