| Summary: | Allow pass variables to default_src_install | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Pacho Ramos <pacho> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | esigra |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
I'd say WONTFIX. I this this was rolled over multiple times, and it's against the interface we'd like to have. Inlining the default is not really an issue. Looking to bin/ebuild-helpers/emake it seems emake could get the needed variables from ${MAKEOPTS} (are we allowed to use this var for that... or should only be used for -j* stuff), "$@" (but default_src_install will not allow that to work) and ${EXTRA_EMAKE} (but... I wasn't trying to use that as I wasn't sure it was a portage specific thing :/)
MAKEOPTS is for the user and you're not supposed to touch it. (In reply to Pacho Ramos from comment #2) > Looking to bin/ebuild-helpers/emake it seems emake could get the needed > variables from ${MAKEOPTS} (are we allowed to use this var for that... or > should only be used for -j* stuff) this was a question, but I didn't type the "?" Also, allowing to pass needed variables to emake install would also benefit other eclasses that wouldn't need to reinvent the wheel in multiple places (like gnome2.eclass, xfconf.eclass, bsdmk.eclass...) (In reply to Michał Górny from comment #1) > I'd say WONTFIX. I this this was rolled over multiple times, and it's > against the interface we'd like to have. Inlining the default is not really > an issue. WONTFIX. A default is a default. If you want something different from it, the ebuild must be slightly more verbose. |
Hello, Currently, we are not able to rely on "default" for src_install because sometimes we need to pass some variables to, for example, fix install locations like: default udevrulesdir="$(get_udevdir)"/rules.d The problem is that default doesn't honor them, then, we need to reinvent the wheel and try to mimic the behavior as close as possible with something like this in the eclass: emake DESTDIR="${D}" $@" install For now I guess we can try to mimic the behavior making our eclass default_src_install do: emake DESTDIR="${D}" $@" install einstalldocs to be "similar", but I was wondering if this situation of needing to pass variables to make install was considered (maybe for a future EAPI). Thanks