Hi,

This sounds like a good proposal to me. However, could you please wait with the 
release until we have completed the migration to Qt. That would be helpful in 
clarifying the project governance and trademark issues that the current setup 
has.

Also, I need you guys to tell how you want the Qt project maintainer positions 
to be assigned.

Cheers,

ma.

On Feb 8, 2012, at 18:49, ext Hugo Parente Lima wrote:

> My proposal is:
> 
> - Move APIExtractor to Shiboken project, then APIExtractor would be compiled 
> as a static library and linked to Shiboken.
> - Remove GeneratorRunner, i.e. merge it into Shiboken.
> 
> Pros:
> 
> - No package/repository/etc for ApiExtractor.
> - No need to worry about ApiExtractor ABI, just remember that ApiExtractor 
> nowadays isn't "library ready", i.e. it doesn't use d-pointers and all the 
> basic stuff that all library code must have to reduce the headache of dealing 
> with ABI that can't be broken.
> - No package/repository/etc for GeneratorRunner: nowadays it's just a thin 
> layer used to load the generators as plugins, but it's not fully decoupled 
> from the generators itself and doesn't have the ability to identify plugin 
> versions.
> - Release PySide will be easier: less packages, less binaries, less files to 
> be 
> installed on the system.
> - Compile PySide will be easier: No need to compile and install various 
> projects in some determined order, you just need two things, Shiboken and 
> PySIde.
> - Increase generator speed: this is a minor increase due to the fact that 
> there wont be the overhead generated by inter shared objects calls
> 
> Cons:
> 
> - We will somehow loose a never used flexibility: Today is possible to use 
> ApiExtractor in other projects to gather information about C++ files, but his 
> was never made by anyone (at least anyone told us), maybe due to the fact 
> that 
> ApiExtractor requires a lot of things that only makes sense on "Binding 
> Generation World", because it's internals aren't documented enough, etc.
> 
> The fact is that this flexibility was never used and I believe it will never 
> be, and in any case ApiExtractor will be available as a static library inside 
> Shiboken (git submodule?) so if someone want to use it, it'll be there.
> 
> 
> If nobody is against this proposal, I can do this before the next release 
> (some day after 18/feb)._______________________________________________
> PySide mailing list
> [email protected]
> http://lists.pyside.org/listinfo/pyside

_______________________________________________
PySide mailing list
[email protected]
http://lists.pyside.org/listinfo/pyside

Reply via email to