[Gs-devel] Re: Dynamic driver loading
raph at levien.com
Thu Feb 1 15:11:56 PST 2001
On Thu, Feb 01, 2001 at 01:22:21PM +0100, LOUIS-SIDNEY Rodolphe wrote:
> I don't have all the built platforms of Ghostcript ...
> I try to put the code in a one file. But we can do differently. Put a code
> for a specific platform (gp_*.c) , it will be different, dependent the
> facilities of the platform.
> We have one point of beginning ... Perhaps it will better to use libtools ?
I don't think so. Libtool is complex and messy, and generally only supports
Unix systems. So we certainly won't be relying on it.
It's _possible_ we'll be using autoconf as an optional, parallel build
system for Unix. This will be useful for checking the existence of
dlopen() and related calls, as is currently done in glib, a good
reference for a dynamic module loading facility.
> > The formatting and indentation of Sidney's code is not consistent
> > with Ghostscript standards (nor with itself). Among other things, this
> > gives a bad impression. To get accepted, a patch will have to have
> > neat, clean formatting.
> This code to be improved, it's an alpha code to show it will be possible to
> do it :)
> I 'am conscious it is not a perfect code and it have somme lack functions
> like versionning,
> emumerations of driver. I modify the postscript code and not implement the
> install the code to be functionnal ...
> ( Are you a little maniac or too perfectionist ?)
Yes, I am afraid that I am a bit of a perfectionist when it comes to
fundamental changes in the Ghostscript core code. There is a lot that
can go wrong here, and I don't want to make any more users unhappy than
Peter has also been quite a perfectionist in terms of accepting patches
into Ghostscript, but in somewhat different ways than myself.
> I a not a real computer scientist, not known about all the rules for
> programming, and organising code. There is more big difficulties to resolve
> I think.
> The best for us is to a precise idea of what we want to do and how to do it.
> I don't have enough knowledge of the internal mecanisms of ghostscript and
> how to do for the best. I'am convinced we need the best of ian's code and
> mine to reach our goals. I don't have THE SOLUTION.
Sure, that's why we're discussing it now. Thanks very much for your
original code and all the followup discussion - it's been very helpful
in moving this project along. I think the best thing is for the discussion
here to result in constructive criticism, and refine the design and
implementation until we're all happy with it.
More information about the gs-devel