[gs-devel] Re: supporting COMPILE_INITS when cross-compiling |

Leonardo leonardo at artifex.com
Thu Feb 23 04:45:33 PST 2006


> or let me know and I will do it.

I prefer you to do that because you've got
a technology for testing this stuff.
Probably need to test that the resources,
which were defined in gs_stres.ps
are still working.


----- Original Message ----- 
From: "Ray Johnston" <ray.johnston at artifex.com>
To: "Leonardo" <leonardo at artifex.com>
Cc: "Ralph Giles" <ralph.giles at artifex.com>; <gs-devel at ghostscript.com>;
<tech at artifex.com>; <miles.jones at artifex.com>
Sent: Thursday, February 23, 2006 4:10 AM
Subject: Re: supporting COMPILE_INITS when cross-compiling | xefitra

> Leo,
> As far as I can tell the gs_resst.ps module should be deleted.
> If it's only use was to support resources that were part of
> gs_stres.ps, then it is no longer needed as the older method
> of including Resource files when COMPILE_INITS=1 is replaced
> by the newer more efficient and robust (and more easily maintained)
> mkromfs function.
> I already deleted lib/gs_stres.ps. The gs_resst.ps is referenced
> by gs_res.ps. If gs_resst.ps can now be deleted (including the
> reference from gs_res.ps) please do so, or let me know and I
> will do it.
> When I deleted the gs_resst.ps and the reference to it from
> gs_res.ps it builds and runs fine for me with and without
> Thanks for noticing this.
> Regards,
> Ray
> __________________________________________________________________
> Leonardo wrote:
>> Ray, Ralph,
>> I'm not sure whether it is relevant or not.
>> Maybe will need some improvements to gs/lib/gs_stres.ps,
>> gs/lib/gs_resst.ps,
>> which deals with "static" resources with COMPILE_INITS=1.
>> Leo.
>> ----- Original Message ----- From: "Ralph Giles"
>> <ralph.giles at artifex.com>
>> To: <gs-devel at ghostscript.com>
>> Cc: <tech at artifex.com>; <miles.jones at artifex.com>
>> Sent: Thursday, February 23, 2006 2:17 AM
>> Subject: supporting COMPILE_INITS when cross-compiling
>>> All,
>>> Ray recently completed an implementation of a '%rom%' iodevice
>>> in Ghostscript, backed by a compressed filesystem image linked
>>> into the binary as static data. This lets us replace the tedious
>>> old way of doing COMPILE_INITS and compiled-in fonts with a
>>> much cleaner unified tree.
>>> Unfortunately, it's been written using existing code from Ghostscript
>>> which breaks cross compiles since zlib and a fair subset of of the gp_*
>>> infrastucture must be compiled for the host so mkromfs can be linked
>>> and executed to generate a gsromfs.c for the target. This also won't
>>> work with the MacOS CodeWarrior build, which uses a similar distinction
>>> between host and target compilation to generate a project file.
>>> I think the dependence on other gs source code can be removed without
>>> too much pain, but we still need zlib. One option is to insert duplicate
>>> makefile rules for all the dependent sources using $(CCAUX) instead of
>>> the usual $(CC). I don't really like that; it seems painful even by the
>>> standards of our build system.
>>> Not supporting this on the CodeWarrior build would be reasonable, but
>>> half the point of the feature is embedded deployments where cross
>>> is the norm, so I think we have to do something. Opinions?
>>> -r

More information about the gs-devel mailing list