[gccsdk] Building package gettext

Peter Naulls peter at chocky.org
Fri Dec 4 13:04:55 PST 2009


Jan-Jaap van der Geer wrote:
> On Mon, 2009-11-23 at 10:33 -0800, Peter Naulls wrote:

>> I may want to overload this differently, for the case of multiple apps
>> in one package.  But anyway, apart from the mechanics, can you describe
>> what it is you are trying to archive here, since I'm not really sure of
>> that.  There is probably a better way to do both things.
> 
> The idea is that the third parameter takes the name of the package where
> the appdir should be created. In that way, the appdir can be created in
> the correct place in $D, since that what was missing was the packagename
> from AB_PACKAGES in which the appdir should have been created.

Ok, I'm still not entirely satisfied with this situation, but I have
done something along these lines.   The changes you suggested to your
setvars should work.

What I've done is to make it always create that package directory, even
for a single package (and you no longer need AB_PACKAGES variable).

libjpeg is of particular note here - it creates a tools package (in
the graphics section), a dev package (these are in the Library section,
but should be in the Development one) and will also later have a shared
library package (in the Library section).  I still need to have some
automation to handle the boiler plate for these two, which will be
relevant to almost all library packages.

There's also some assumptions in add-riscpkg about there only being
one !Boot file - this broke for example Wesnoth.  For now, I just choose
the top level one (there's another in !MyWesnoth).

Finally, I want to do away with reliance on !Unixhome.  In many cases,
programs will work fine without it, and create their choices in
Choices$Write (but sometimes this fails due to nested dirs, etc) but
will fall back to !UnixHome if they see it.  Many apps do however, have
explicit code to use Choices$Write.   One option here is to simply
modified the existing code for getenv("HOME") in UnixLib.





More information about the gcc mailing list