pygccxml-development

[pygccxml-development] Relative path mismatch

[Kevin B. <kev...@gm...>]

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.

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?

Thanks,

--- Kevin

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/

Re: [pygccxml-development] Relative path mismatch

[Kevin B. <kev...@gm...>]

> 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.

User would have to regenerate the build script (makefile, jamfile, whatever) 
every Py++ run to make use of that, though.

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

Thanks, this strips the leading path cruft from the #include directives, which 
is quite acceptable.

It's not actually necessary to do the os.path.abspath() call. It works with 
the relative paths as well.

Naturally, you have to append *both* the lib include *and* the destination 
source folders to user_defined_directories to get both categories of #include 
directives stripped.

--- Kevin

Re: [pygccxml-development] Relative path mismatch

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

On 9/26/06, Kevin Bluck <kev...@gm...> wrote:
> > 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.
>
> User would have to regenerate the build script (makefile, jamfile, whatever)
> every Py++ run to make use of that, though.
>
> > mb = module_builder_t( ... )
> > mb.build_code_creator( ... )
> > my_dir = os.path.abspath('.') #for example
> > mb.code_creator.user_defined_directories.append( my_dir )
>
> Thanks, this strips the leading path cruft from the #include directives, which
> is quite acceptable.
>
> It's not actually necessary to do the os.path.abspath() call. It works with
> the relative paths as well.

os.path.abspath was just an example, you can replace it with whatever you want.


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