| 1 |
Mike Frysinger wrote: |
| 2 |
|
| 3 |
> On Saturday 01 August 2009 11:22:41 Steven J Long wrote: |
| 4 |
>> Mike Frysinger wrote: |
| 5 |
>> > On Tuesday 21 July 2009 06:13:25 Steven J Long wrote: |
| 6 |
>> >> Nikos Chantziaras wrote: |
| 7 |
>> >> > Thanks. I ended up doing it this way, though with only one loop in |
| 8 |
>> >> > src_install(), which seems to be a bit more efficient and shorter: |
| 9 |
>> >> > |
| 10 |
>> >> > |
| 11 |
>> >> > LANGUAGES="de" |
| 12 |
>> >> > for i in ${LANGUAGES}; do |
| 13 |
>> >> > IUSE="${IUSE} linguas_${i}" |
| 14 |
>> >> > done |
| 15 |
>> >> |
| 16 |
Oh, don't forget to: unset LANGUAGES # unless you need to reexamine it in |
| 17 |
later phases. |
| 18 |
|
| 19 |
>> >> Just on a side-note (not saying it's how you want to do this one), |
| 20 |
>> >> this is something that BASH arrays are nice for (saving another loop): |
| 21 |
>> >> $ foo=(bar baz quux) |
| 22 |
>> >> $ echo "prefixed: '${foo[*]/#/pfx_}'" |
| 23 |
>> >> prefixed: 'pfx_bar pfx_baz pfx_quux' |
| 24 |
>> > |
| 25 |
>> > printf would probably be better as it is typically a shell builtin and |
| 26 |
>> > it doesnt require use of arrays/uncommon syntax. |
| 27 |
>> > media-gfx/exiv2/exiv2-0.18.ebuild: |
| 28 |
>> > IUSE_LINGUAS="de es fi fr pl ru sk" |
| 29 |
>> > IUSE="${IUSE} $(printf 'linguas_%s ' ${IUSE_LINGUAS})" |
| 30 |
>> |
| 31 |
>> Doh, forgot about printf. (We have alias print="printf '%s\n'" in our lib |
| 32 |
>> code which comes in handy too.) Nice one. |
| 33 |
>> |
| 34 |
>> The only issue with the above is that it requires a subshell; forking |
| 35 |
>> isn't cheap (especially on Interix/cygwin/doze) and in general it's |
| 36 |
>> considered a bit lame (at least amongst the ##bash old-timers that I bump |
| 37 |
>> heads with) to need forking in BASH, though ofc not in SH, which is why |
| 38 |
>> it might not be the best here, since the metadata generation phase is a |
| 39 |
>> restricted subset of SH, leave alone BASH, at least aiui. |
| 40 |
> |
| 41 |
> forks are cheap on any sane *nix box |
| 42 |
They certainly are in comparison to doze; however they are still a load of |
| 43 |
work, even with copy-on-write. I've done loads of BASH, and quite large |
| 44 |
scripts; believe me that eliminating subshells makes things quicker. |
| 45 |
(Don't forget BASH is more of a pig than most sh.) In the context of cache |
| 46 |
generation, we've heard lots about it being slow on -dev; eliminating |
| 47 |
subshells, where appropriate, is one of those things that can make it |
| 48 |
quicker without needing to bastardise the format. |
| 49 |
|
| 50 |
> , and subshells/builtins are better than external programs. |
| 51 |
That's true enough, since the main shell has to fork for any external, and a |
| 52 |
fork plus builtin is better than fork + load an external. We're not using |
| 53 |
an external at all here though, so I don't see how it applies. |
| 54 |
|
| 55 |
> i'm pretty sure the overhead here tends to be less |
| 56 |
> than the overhead of running for loops, especially as the LINGUAS gets |
| 57 |
> bigger. |
| 58 |
Timings would settle it; a for does append to a string on each iteration. |
| 59 |
Which is why parameter expansion on arrays is so nice: we don't even need a |
| 60 |
loop and BASH can do it as part of the expansion it always has to do |
| 61 |
anyhow. It does speed things up. |
| 62 |
|
| 63 |
Only other change is: LANGUAGES=(en de fr) # or the like vs: LANGUAGES='en |
| 64 |
fr de'. LANGUAGES="de" will work, but only for single values. Recently |
| 65 |
there's been more usage of arrays in eclasses; I don't think expecting |
| 66 |
people to learn the syntax for the language, over time, is that big an ask. |
| 67 |
After all, it's certainly more transferable than learning the ins and outs |
| 68 |
of an EAPI. |
| 69 |
|
| 70 |
Having said that we allow the user to use either arrays or strings split on |
| 71 |
spaces for configuration of update[1]. I didn't want to get into the |
| 72 |
isArr() function here since it uses a subshell ;) I was against the use of |
| 73 |
both, as I saw no reason a user couldn't use an array, and thus learn a bit |
| 74 |
more BASH, but a forum-user talked me into it. For an end-user wrapper for |
| 75 |
emerge, it seems fair enough. But for writing and maintaining ebuilds (the |
| 76 |
definition of what a Gentoo developer is)? Expecting people to deal with an |
| 77 |
array-configured value is useful for the eclasses they might come across |
| 78 |
later, and means eclass authors can use them without worrying. |
| 79 |
|
| 80 |
Regards, |
| 81 |
Steve. |
| 82 |
|
| 83 |
[1] http://forums.gentoo.org/viewtopic-t-546828.html (get git version if you |
| 84 |
want to try it though.) |
| 85 |
-- |
| 86 |
#friendly-coders -- We're friendly but we're not /that/ friendly ;-) |
Archives