Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 608280 - Allow pass variables to default_src_install
Summary: Allow pass variables to default_src_install
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2017-02-05 08:44 UTC by Pacho Ramos
Modified: 2017-09-08 18:18 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2017-02-05 08:44:39 UTC
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
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-02-05 09:56:30 UTC
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.
Comment 2 Pacho Ramos gentoo-dev 2017-02-07 12:38:33 UTC
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 :/)
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-02-07 12:39:53 UTC
MAKEOPTS is for the user and you're not supposed to touch it.
Comment 4 Pacho Ramos gentoo-dev 2017-02-07 12:49:23 UTC
(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...)
Comment 5 Ulrich Müller gentoo-dev 2017-09-08 18:18:32 UTC
(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.