Hello Simon, 2010/3/25 Simon Richter <[email protected]>: > $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." -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
