what i mean that after all the magic is done, it ends up with a
command line like that:
cc -I. -I../../../../../include -K udk -KPIC \
-I../../../../../source/hbzlib -I/usr/include -c \
../../../_hbhbpdf.c -o_hbhbpdf.o
(wrapped for clarity). would it be too cumbersome to by some means
filt
On Wed, 12 Aug 2009, Viktor Szakáts wrote:
> > what i mean that after all the magic is done, it ends up with a
> > command line like that:
> >
> > cc -I. -I../../../../../include -K udk -KPIC \
> > -I../../../../../source/hbzlib -I/usr/include -c \
> > ../../../_hbhbpdf.c -o_hbhbpdf.o
i see it's to check for the presence of png.h, and such techniques
are
used elsewhere too. would filtering /usr/include out of the include
list be too cumbersome?
I'm not sure I understand. Could you tell some more about this?
what i mean that after all the magic is done, it ends up with a
c
On Wed, 12 Aug 2009, Viktor Szakáts wrote:
hi,
> > 39 ifeq ($(HB_XBUILD),)
> > 40 HB_INC_LIBPNG = /usr/include
> >
> > is there any reason for explicitly specifying /usr/include here? it'll
> > be picked up by the compiler anyway, but now i've found a case where
> > it _might_ cause some l
Hi,
external/libhpdf/Makefile
39 ifeq ($(HB_XBUILD),)
40 HB_INC_LIBPNG = /usr/include
is there any reason for explicitly specifying /usr/include here? it'll
be picked up by the compiler anyway, but now i've found a case where
it _might_ cause some level of harm - probably not in hpdf, though,
