Summary: | [Future EAPI] package manager should export variables for compilers, linkers and alike | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Xake <kanelxake> |
Component: | Core - Ebuild Support | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | blueness, esigra, pacho |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 |
Description
Xake
2010-10-19 12:45:19 UTC
tc-export is only there for packages that dont respect the env vars themselves already. it isnt the business of the PM to break down the CTARGET/CHOST logic and come up with appropriate CC/CXX/etc... values. in other words, you're proposing we integrate toolchain-funcs.eclass into every PM which sounds like a bad idea. i dont see this being a problem that needs addressing at the PM level. (In reply to comment #1) > tc-export is only there for packages that dont respect the env vars themselves > already. I try to parse this, and I fail to understand. Currently if I do a ebuild with just a src_compile() { echo "${CC}" "${CXX}" } and run "ebuild test-1.ebuild compile" I get a empty line, unless I specify CC and CXX in my own env, then portage picks this up. Is this the env vars you are talking about (i.e. if the package uses scons and you do not have "tc-export CC CXX" then what you have in your .bashrc should be used)? Or in other words every ebuild should themselves specify tc-export unless they use a eclass that already do this (else the outcome of the merge is hard-predicted)? *** Bug 435786 has been marked as a duplicate of this bug. *** *** Bug 408693 has been marked as a duplicate of this bug. *** (In reply to SpanKY from comment #1) > tc-export is only there for packages that dont respect the env vars > themselves already. You are running on assumptions here. Indeed, most of GNU configure scripts default to using ${CHOST}-gcc but that isn't always true. So we end up somewhere near 'you need to export CC unless some logic in configure always comes up with our preferred CC'. It should be noted that autoconf supports overriding the compiler search list in AC_PROG_CC (AC_PROG_CXX). Then, some projects actually prefer clang over gcc, and then your assumption falls apart and we need to export CC. I think it would be good for consistency to have at least CC and CXX exported everywhere. As far as I'm concerned, the default values may come from profiles much like CFLAGS do. I am not sure if this could be reviewed for the next eapi :/ If the values get set in profiles, no PMS change would be necessary. To be honest, this is really a configuration/profile problem and not PMS. PMS doesn't tell anything to set CFLAGS, LDFLAGS etc. -- it's set by profiles and default configs. I think CC, CXX, etc. should be covered the same way. (In reply to Michał Górny from comment #8) > To be honest, this is really a configuration/profile problem and not PMS. > PMS doesn't tell anything to set CFLAGS, LDFLAGS etc. -- it's set by > profiles and default configs. I think CC, CXX, etc. should be covered the > same way. Closing. |