[C++-sig] pyste -I

[Jason.Sibthorpe at aculab.com]

Hi Nicodemus,

Thanks for your response.

>Is there any reason that you can't hardcode the paths into the Pyste
>files?

Yes and no.

The problem as I see it.

Hardcoding relative paths doesn't work if you generate the .cpp in a
different location to that in which you compile your sources.  The
-output option doesn't help you here.

Hardcoded absolute paths are the work of the devil.  Sharing generated
sources between my project members requires changes to the sources and
windows paths don't work on Solaris nor Linux etc

Surely this is exactly what the -I option if for?

If you agree, I can lend a hand with the implementation.  I already 
have code that parses files for include directives, (albeit in c) the
port should be easy.


-Jason

-----Original Message-----
From: Nicodemus [mailto:nicodemus at globalite.com.br]
Sent: 08 September 2003 22:54
To: Development of Python/C++ integration
Subject: Re: [C++-sig] pyste -I


Hi Jason,

Jason.Sibthorpe at aculab.com wrote:

>Hi,
>
>The -I option to pyste doesn't appear to work as I expect.
>
>Invoking pyste without the -I option results in the following error
>"    raise RuntimeError, 'Header file "%s" not found!' % name
>RuntimeError: Header file "rc-engine.hpp" not found!"
>
>As I would expect.
>
>Invoking pyste with -I../ does not raise an error and source files
>are generated but the body of the Export_*() is empty and include
>directives are missing.
>

The -I option is intended only to be passed along to gccxml, not for use 
with Pyste itself. GCCXML, like any compiler, must process all the 
header files included by your source file.
Is there any reason that you can't hardcode the paths into the Pyste files?

Regards,
Nicodemus.


_______________________________________________
C++-sig mailing list
C++-sig at python.org
http://mail.python.org/mailman/listinfo/c++-sig