[pygccxml-development] Re: Small patch for two things

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 5/16/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman:
>>
>> I have attached a patch to pyplusplus that adds to things.
>>
>> - In module_builder/builder.py
>>
>> Add decl_headers parameter to build_code_creator method.  This is just
>> passed on directly to creator.create() to allow the user to overried the
>> headers used.
>>
>> - in module_t code creator
>>
>> Extended adopt_include method so it can take directory names (string's)
>> directly.  It will check the type and automatically create an include_t
>> behind the scenes if it is needed.  This makes it a little easier to add
>> includes to the code creator returned from the module_builder and makes
>> it so the users don't need to know about the code creator types.
>
>
> :-). I am a little bit ill, so I have some time to work on py++.
> This is exactly the problem I found and implemented an other solution.
>
> I am not sure which one is better( easier to understand, correct ).
> My solution is next:
> To module_t code creator I added new function:
>    replace_included_headers( list of headers( == strings )
>                                                ,
> leave_boost_python_header=True  )
>
> So user needs to call this function.
> Now comparison:
>
> What is bad in my implementation: user needs to take a look on module_t
> code creator.
>
> What is not so good in your implementation: it is not extensibility. I
> am sure, that
> there are inconveniences or bugs in interface of code creators, that
> you will not
> be able to fix by passing argument to build_code_creator.
>
> I am not sure with what implementation to go. Thoughts?

I am fine with either.  They really do the same thing behind the 
scenes.  Mine could be easier to understand since the user sees it as 
part of their method call, but I am not going to argue it either way.

What about the other patch, the one that allows adopt_include to take a 
string as an argument?

-Allen