Re: [pygccxml-development] Header path normalization and cross-platform code
Brought to you by:
mbaas,
roman_yakovenko
|
From: Roman Y. <rom...@gm...> - 2009-04-23 17:37:48
|
On Thu, Apr 23, 2009 at 12:44 AM, Patrick Hartling
<pat...@pr...> wrote:
> I am working on setting up a development environment where team members can
> run Py++ from Linux, Windows, or Mac OS X. Thus far, we have struggled to
> get GCC-XML to handle our code on Windows, but we are getting very close to
> having that resolved. In the process, I have come across some unexpected
> behavior from Py++. Specifically, use of the static method
> pyplusplus.code_creators.include_directories.include_directories_t.normalize()
> produces code on Windows that will not compile on other platforms. For
> example, if I have a class MyClass, Py++ on Windows generates code that
> references the .hpp file as myclass.pypp.hpp. The generated file, however,
> will be named MyClass.pypp.hpp. This won't work on a case-sensitive file system.
Basically, in this moment you introduced a new use case to the
project. This use case is problematic:
1. In many cases, the generated code could\will be a little bit
different. For example, boost::date_time library uses different
integer types to represent\keep time. The generated code will be
different on Windows and on Linux.
2. Even if your generated code is ( could be ) same for all platforms,
I cant promise you, that I will not break this feature in future - I
don't enough resources to run such tests.
In most cases, I deliver Py++ script which handles the differences
between platforms and generates the code.
If you need this feature, I suggest you to submit a patch - I will be
glad to commit it.
> The second issue is with the directory separator. If I use
> pyplusplus.code_creators.module.module_t.replace_included_headers() and tell
> Py++ to include a file such as <dir/SomeHeader.h>, the generated output on
> Windows will reference <dir\someheader.h>. Again, the case-sensitive name is
> lost, and the directory separator has changed to be one that only works when
> building on Windows.
What about Mac OS? Will '/' work on it too? ( I never worked on Mac. )
> Is there a specific need for header path normalization?
If I remember right, Py++ has few functions ( don't remember what are
they ), that work with paths. Introducing path "normalized" form
greatly reduces bugs in that functions. I think, if you turn off
normalize functionality, Py++ will introduce few bugs here and there.
As with previous problem, if you submit the patch I'll gladly accept it.
> Under typical
> circumstances, I would expect that the UNIX-style path would always work on
> Windows. At the moment, I can't think of an example of when it would not. If
> header path normalization cannot be removed, could an option be added to
> pyplusplus.code_creators.include_directories.include_directories_t so that
> the use of header path normalization can be turned off? Given that it is a
> static method, a class variable for include_directories_t or a global
> variable for the pyplusplus.code_creators.include_directories module would
> do the job.
You also can replace both functions and submit the patch later :-)
import pyplusplus
def your_function( ..... ):
<<< .... >>>
pyplusplus.code_creators.module_t.replace_included_headers = <<<your function>>>
HTH
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|