[GCC-XML] Relative paths in GCCXML

[Chris Friedemann]

Sorry, I guess I should have been more clear.

What I'm confused as to if I run gcc-xml on a .h file that has an include
preproccesor definition that contains a fully specified path like:

#include "C:\dev\dirA\dirB\dirC\header.h"

then it works without using the -I flag at all.

However, if the path is not fully specified like this:

#include "../../dirC/header.h"

then I get the "could not find file header.h" error message.  Neither of
these examples use the -I flag, but one works and the other doesn't.  I'm
just curious as to the reason why.


On 9/25/07, Brad King <brad.king at kitware.com> wrote:
>
> Chris Friedemann wrote:
> > I recently inherited a system that uses GCC to reflect values from c++
> > to xml as well as a couple of other things.  Part of my task was to
> > remove the dependencies of VS 7.1 from the system, and the main culprit
> > there was the version of gcc-xml we were using.  I got the latest
> > version off of the CVS depot, but now I've hit another problem.
> >
> > In each of the files that we are passing to gcc-xml, there is an
> > #include definition that points to a file that contains common
> > definitions etc.  It uses a relative path, such
> > as "../../dirA/dirB/header.h".  After upgrading the gcc-xml version,
> > I now get errors that it cannot find " header.h" as specified by the
> > path.  If I make the path fully explicit then it works (ie
> > C:\dirC\dirA\dirB\header.h), but it won't if it has the "../" in the
> > path name.
> >
> > Does anyone know of a solution or workaround for this issue?
>
> GCC-XML is just like any other compiler in terms of the preprocessor (in
> fact it simulates the preprocessors of other compilers).  Include
> directories must be specified with -I flags.
>
> -Brad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/gccxml/attachments/20070925/8c2a3a81/attachment-0001.html>