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

Ray Johnston ray.johnston at artifex.com
Wed Feb 22 17:10:19 PST 2006


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
COMPLILE_INITS=1.

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