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