Re: [pdf-devel] Testing pdf.h.

[Aleksander Morgado]

> ###
> In file included from test.c:2:
> /usr/local/include/pdf.h:159:27: error: gl_array_list.h: No such file or
> directory
> In file included from test.c:2:
> /usr/local/include/pdf.h:359: error: expected specifier-qualifier-list before
> ‘gl_list_t’
> /usr/local/include/pdf.h:446: error: expected declaration specifiers or ‘...’
> before ‘FILE’
> ##
>
> If gl_array_list.h is carried within the library sources I'm not sure if it
> should be included in the library public interface pdf.h.

At least the definition of `gl_list_t' (in gl_list.h) is needed in 
pdf.h. I don't think it's a good idea to include the full header from 
gnulib within the pdf.h file.

How about redefining the contents of `struct pdf_stm_s' to avoid using 
gl_list_t? As this type is a pointer, we could use (void *) instead for 
the `read_filter_list' and `write_filter_list' variables. Another option 
could be to use (void *) instead of `pdf_stm_t' directly.

Including in pdf.h the real definition of gl_list_t coming from 
gl_list.h would imply modifying the original file, what I also don't 
think is a good idea taken into account that it comes from `gnulib-tool 
import'.

What do you think?

> Shouldn't libs in libgnupdf/libs be compiled inside libgnupdf.so ?

I don't really know much of the GNU Portability Library, but from the 
README: "These are files intended to be shared at source level; Gnulib 
is not a library meant to be installed and linked against it". So, I 
guess we shouldn't create a separate libgnu, and then link against it. 
As Gerel says, the Gnulib sources should be compiled within the gnupdf 
library. This would allow to skip problems if any other software package 
generates another gnulib with other modules than the ones imported for 
gnupdf. Am I right?

> Moreover, has anyone tried that test succesufully ?

Never did an installation of the package before. I am testing the 
software directly with new Check suites in the torture chamber.



-Aleksander