Ok, so imagine I have: IUSE="ipv6 dvdr" And then I want to have econf auto use_enable dvdr and have it auto use_with ipv6. Also, I want to pass --with-system-zlib to configure. Normally I'd do this: src_configure() { econf $(use_enable dvdr) \ $(use_with ipv6) \ --with-system-zlib } But if we had these variables, these things would be simpler: DEFAULT_SRC_CONFIGURE_ENABLES="dvdr" DEFAULT_SRC_CONFIGURE_WITHS="ipv6" DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS="--with-system-zlib" I think this whole proposal should only happen after we have src_compile split but that's just my opinion. Another thing that would be useful would be able to pass options to emake in src_compile(), like so: Original: src_compile() { emake buildtarget || die "Build failed" } New: DEFAULT_EMAKE_PARAMS="buildtarget" ( or some other interesting variable name. )
You forgot to assign the bug. :)
I should probably mention, that the original credit for this idea goes to the people who wrote the exheres format...This makes the exheres much nicer for the simple cases.
Perhaps a better way to do this would be: DEFAULT_SRC_CONFIGURE_ENABLES=( "ssl crypto" ) which would translate to $(use_enable ssl crypto).
Created attachment 163759 [details, diff] default-config.patch This patch enables two new variables, DEFAULT_CONFIG_ENABLE and DEFAULT_CONFIG_WITH both of which are checked as arrays to enable the use case you specified, the third zlib thing is already covered by EXTRA_ECONF. Slight concern would be if the third argument being passed to use_with has a space in; let me know if that's an issue; obviously needs to be tested properly ;)
The zlib thing isn't covered by EXTRA_ECONF; that's a user variable not to be touched by ebuilds.
(In reply to comment #5) > The zlib thing isn't covered by EXTRA_ECONF; that's a user variable not to be > touched by ebuilds. > The eclass doing EXTRA_ECONF="--with-system-zlib $EXTRA_ECONF" is not going to affect what the user has sent through in any way, though, and the user terms will still be in the same relative position as if the parameter had been passed to the econf call. So would achieve the desired solution with no effect on functionality already in-place.
Created attachment 164744 [details, diff] Implement the src_configure()
Er, that patch description doesn't say so, but it also implements the src_compile stuff as well.
What is blocking this? I haven't seen much disagreement here, but maybe it was strongly discussed long time ago and I missed it :|
The Council voted against it when DEFAULT_ was introduced.
WONTFIX then?
So WONTFIX.
