pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] Sources organization


From: jemarch
Subject: Re: [pdf-devel] Sources organization
Date: Tue, 22 Jan 2008 14:06:40 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.0.93 (x86_64-unknown-linux-gnu) MULE/5.0 (SAKAKI)

   >    2.a) One library with conditional compilation of some layers
   >
   >         In this scheme a single library called libgnupdf.(so|a) would
   >         be constructed. The user would select the layers to be
   >         included in the library using a `configure' switch like:
   >         --with-pdf-level=(page|document|object|base).
   >
   >         Then if the `document' level is selected the library will
   >         contain the code of the base, object and document layers.
   >
   >         In this way we would achieve flexibility: a client application
   >         may want to manipulate the contents of a PDF document in order
   >         to extract text or metadata (like libextractor). The `page'
   >         layer is not needed in this scenario (nor the dependency with
   >         libcairo, for example). That client application would want to
   >         link against a `--with-pdf-level=document' compiled libgnupdf.
   >
   >         The libray would then distribute a single `pdf.h' file
   >         granting access to the functionality of all the enabled
   >         layers.
   >

   IMHO this approach would be better. I guess that the number of
   specific user cases where there is a need for linking to a lower layer
   will be low, comparing with the need for having the full set of
   layers. The default configure would work at page level, including all
   the lower levels, and only in specific user cases an additional
   configure option would be passed to skip higher level layers. If you
   really think that there will be lots of user cases where only a subset
   of layers is needed, then the four-libraries approach could be
   better.

I agree.

   >    4.b) Carry layer information in symbol names only

   If sources are stored in a layer-basis directory structure, as in
   option 3.b, there is no need for having layer information in the
   source file name. Anyway, it is quite useful to have the layer
   information within the symbol names.

I think that it is important to keep a PREFIX-file.[ch] <->
PREFIX_symbol equivalence in the sources even if we use the several
directories schema.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]