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 level of harm - probably not in hpdf, though, > > anyway. > > It's current technique which we use to find out whether a given > external component is available. Such lines as line 40 here used > to contain a list of possible system locations (on *nix systems) > for a header name we'd like to #include in source. It's not perfect, > but it used to work well for our purpose. > > > 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 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 filter out the '-I/usr/include' part, so that it in the end it will not be part of the actual command line? -- [-] mkdir /nonexistent _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
