Re: [pygccxml-development] Header path normalization and cross-platform code

[Patrick H. <pat...@pr...>]

On Apr 23, 2009, at 12:37 PM, Roman Yakovenko wrote:

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

Yes.

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


I will probably just proceed in this way for now. I haven't observed  
any problems by changing  
pyplusplus 
.code_creators.include_directories.include_directories_t.normalize()  
so that it does nothing except return the reference it is passed, but  
I have not tried the Py++ test suite to see if that change exposes  
bugs elsewhere.

  -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

The information transmitted in this communication is intended only for
the person or entity to which it is addressed and contains proprietary
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please destroy any copies, contact the sender
and delete the material from any computer.