Re: [pygccxml-development] Relative path mismatch

[Roman Y. <rom...@gm...>]

On 9/25/06, Kevin Bluck <kev...@gm...> wrote:
> If I do something like this:
>
> sandbox_root = '../../../../'
> foo_inc_root = sandbox_root + 'lib/foolib/include/'
> foolib_h   = foo_inc_root + 'foolib.h'
> gccxml_exe   = sandbox_root + 'build/gccxml/gccxml.exe'
> builder_args = { 'files'                : [foolib_h]
>                , 'gccxml_path'          : gccxml_exe
>                , 'working_directory'    : foo_inc_root
>                , 'include_paths'        : [foo_inc_root]
>                , 'define_symbols'       : None
>                , 'undefine_symbols'     : None
>                , 'compilation_mode'     : None
>                , 'cache'                : file_cache_t('./cache/foolib_h')
>                , 'optimize_queries'     : True
>                , 'ignore_gccxml_output' : False
>                , 'cflags'               : ""
>                }
> builder = module_builder_t(**builder_args)
> # ... Generate code
> builder.build_code_creator(module_name='_foo_base')
> builder.split_module('../cpp/_foo_base/')
>
> Notice the last line. I've added a subfolder. The reason for this is
> that the 'foolib' library has multiple namespaces, and I want each to be
> represented by a different .pyd. '_foo_base.pyd', '_foo_advanced.pyd',
> etc. Each namespace's .cpp filess should be generated into their own
> subfolder so that they can easily be globbed by the build script. Due to
> the nature of split_module() its hard to predict from the build system's
> point of view exactly what cpp files are going to be generated, so
> globbing whatever happens to be in each subfolder is the most
> maintainable strategy.

If you use SVN version, than split_module returns list of generated files and
provides you a way to tell what should be done with "no more in use" generated
files. By default Py++ will delete them.

> However, Py++ doesn't adjust for the extra subfolder when it writes the
> relative path to the header. Each .pypp.cpp file still shows '#include
> '../../../../lib/foolib/include/foolib.h' when it actually ought to have
> another ../ stuck on the front because its being generated into one more
> level down. This also applies to the .pypp.hpp includes. Py++ writes
> '#include ../cpp/foolib.pypp.hpp' when it ought to be '#include
> ../../cpp/foolib.pypp.hpp' Naturally, this breaks the build.
>
> Should Py++ adjust relative paths to account for the actual destination
> of generated files? Or am I failing to configure something properly here?

Py++ does not generate "relative" includes. I remember I had some problems
with relative includes. I don't remember what are they. May I propose another
solution?

mb = module_builder_t( ... )
mb.build_code_creator( ... )
my_dir = os.path.abspath('.') #for example
mb.code_creator.user_defined_directories.append( my_dir )

This should tell Py++ to generate include directives and take into account
some directories. Now from build script you can add the path to directory to
search header files in. I think this solution should work.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/