Gentoo Archives: gentoo-devhelp

From: Steven J Long <slong@××××××××××××××××××.uk>
To: gentoo-devhelp@l.g.o
Subject: [gentoo-devhelp] Re: Re: Re: LINGUAS vs LANGUAGES
Date: Sat, 15 Aug 2009 23:19:43
In Reply to: Re: [gentoo-devhelp] Re: Re: LINGUAS vs LANGUAGES by Mike Frysinger
Mike Frysinger wrote:

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