1 |
On Wed, Oct 19, 2011 at 03:26:21PM -0400, Mike Frysinger wrote: |
2 |
> On Wednesday 19 October 2011 14:53:07 Brian Harring wrote: |
3 |
> > On Wed, Oct 19, 2011 at 02:05:50PM -0400, Mike Frysinger wrote: |
4 |
> > > i wrote a new func for toolchain.eclass: huse. this is because the |
5 |
> > > toolchain.eclass supports multiple versions in parallel, and the IUSE |
6 |
> > > value can vary greatly between them. so doing `use foo` without |
7 |
> > > checking IUSE first doesn't work. since i got a request to use this in |
8 |
> > > other eclasses (for the same reason), i figured i'd move it to |
9 |
> > > eutils.eclass so more people can benefit. |
10 |
> > > |
11 |
> > > now that we have "in_iuse" in eutils.eclass (with all the caveats), i'll |
12 |
> > > be |
13 |
> > > |
14 |
> > > adding huse: |
15 |
> > > huse() { |
16 |
> > > |
17 |
> > > in_iuse $1 || return 1 |
18 |
> > > use $1 |
19 |
> > > |
20 |
> > > } |
21 |
> > > |
22 |
> > > any comments before i publish ? |
23 |
> > |
24 |
> > Call it safe_use. |
25 |
> |
26 |
> safe for who ? that implies to me much more vagueness than "iuse" ... |
27 |
|
28 |
Safe in the sense it does basic IUSE checks prior, so it doesn't |
29 |
trigger QA warnings for when the ebuild doesn't support the flag. |
30 |
|
31 |
Name's a bit off though considering if the host was amd64, `huse amd64` |
32 |
would return 1 since it's not in IUSE. |
33 |
|
34 |
Either way, the 'iuse' naming rather sucks imo; that implies the |
35 |
equivalent of `use` (is this flag in iuse?) rather than "is this flag |
36 |
in iuse and use". |
37 |
|
38 |
If you're primarily doing this to bypass the QA warnings, than jam |
39 |
safe into the name, and/or while making sure the docs are clear about |
40 |
it. |
41 |
|
42 |
Either way, go nuts- rather not get into a bikeshedding discussion on |
43 |
this one. ;) |
44 |
~harring |