On Thu, 13 Sep 2001, Dave Mitchell wrote:
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > > > > changing parrot.h to do #include "parrot/config.h" and
> > > > > then changing
> > > > > Makefile to add -I./include to CCFLAGS.
> >
> Perhaps I'm missing something here, but I always thought that
>
> #include "config.h"
> rather than
> #include <config.h>
>
> would ensure that the local Perl version would get always get picked up in
> preference.
Yes, while you're building Parrot, you're probably right. However, you're
missing at least two things:
1. First, suppose that Parrot's header files (including config.h) have
been installed into /usr/local/parrot/include/... and that someone else
has installed a different config.h into /usr/local/include.
Now, imagine that you're
building an add-on module or
embedding Parrot into another application, and you want to compile and
include some of your /usr/local/ stuff. If you do
cc -I/usr/local/include -I/usr/local/parrot/include/
which "config.h" will you get? The wrong one. Sure, you can rearrange
the order of the -I directives, but that's not always easy to do (may
involve editing a Makefile or series of Makefiles) and indicates a
fragility of design that we'd like to avoid.
2. If parrot.h contains #include "config.h", then "obviously", the C
compiler will look for "config.h" in the same directory as it found
"parrot.h" even if there's a "config.h" earlier in the include chain (e.g.
in /usr/local/include). Right? Alas, no. I don't recall the platform
(and can't easily think of p5p archive keywords to narrow a search), but
I'm sure I received a credible report to the contrary -- possibly from a
Windows C/C++ compiler -- at some point in the past.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
