Sorry if I don't submit a completely wrote-for-bug text, but I really think the gentoo-alt post plus vapier stuff explain quite good the idea :) To: gentoo-alt@g.o Now this is my idea: let CHOST/CBUILD expand to vars (and then to useflags): *-*-linux-* -> KERNEL="linux" *-*-*-gnu -> ELIBC="glibc" USERLAND="GNU" *-*-kfreebsd-gnu -> KERNEL="FreeBSD" ELIBC="glibc" USERLAND="GNU" *-*-freebsd* ->KERNEL="FreeBSD" ELIBC="FreeBSD" USERLAND="BSD" *-*-darwin* -> KERNEL="Darwin" ELIBC="Darwin" USERLAND="Darwin" *-*-netbsd* -> KERNEL="NetBSD" ELIBC="NetBSD" USERLAND="BSD" *-*-solaris* -> KERNEL="Solaris" ELIBC="Solaris" USERLAND="Solaris"(?) Now this could probably be simple to implement. From here we can expand the variables to get the right use-expanded vars as we do now. But that's not enough, as this is valid to set features and dependency we are compiling FOR. If we crosscompile from FreeBSD to Linux, we would get userland_GNU, and that would make a package that uses bsdish make command to depend on pmake and also to run "pmake" instead of "make"... what to do? CBUILD comes to help, as it will represent the system you're building ON. This could add BUSERLAND BELIBC BKERNEL variables and use expands (B for Build like BDEPEND), also if probably BUSERLAND is the only one that would be used. The expansion will occur on portage itself, without having to deal with changes from env to those variables. -- Vapier then came out with this: $ cat env-map *-linux-* KERNEL=linux *-gnu USERLAND=GNU ELIBC=glibc x86_64-* ARCH=amd64 $ cat readmap #!/bin/bash CBUILD=${CBUILD:-${CHOST=${CHOST:-$1}}} [[ -z ${CHOST} ]] && echo need chost unset KERNEL ELIBC USERLAND ARCH while read LINE ; do set -- ${LINE} targ=$1 shift [[ ${CBUILD} == ${targ} ]] && eval $@ done < env-map echo ARCH=${ARCH} KERNEL=${KERNEL} ELIBC=${ELIBC} USERLAND=${USERLAND} $ ./readmap x86_64-pc-linux-gnu ARCH=amd64 KERNEL=linux ELIBC=glibc USERLAND=GNU -- and with the idea of putting that in the profiles/ subdirectory (possibly incremental with overlays, thanks :) ). What would that seem?
Profile bashrc's don't affect the python side of portage at all, at the moment. Hence, it couldn't be used immediately. I definitely like this much more than GLEP22 though. ;) Speaking of which, how would this work with ebuild keywording?
Just a little side-note, GNU/kFreeBSD carries version info in the triplet, e.g. x86_64-pc-kfreebsd5.4-gnu So instead of *-*-kfreebsd-gnu, you need *-*-kfreebsd*-gnu.
Btw, why do you need this "readmap" thing. Can't these variables in /etc/make.conf just be made mandatory? It doesn't even need to be mandatory for all platforms, if you assume that non-existance of the vars implies *-*-linux-gnu.
The point of all this is to make sure that they are not tricked by users breaking systems in untoldable ways. I think this is just waiting for the new GLEP to be presented, discussed and, hopefully, accepted.
What's the status on this? Mind that if this is supposed to affect $USE (via USE_EXPAND) you can't use a bash solution (as mentioned in comment #1) and I don't see this restriction changing anytime soon.
Anyone still going for this?
closing due to apparent lack of interest
