pygccxml-development

[pygccxml-development] Phisical (re)design

[Roman Y. <rom...@gm...>]

Hi. As decided, development of pyplusplus is going to switch to SVN.

Here is a proposed phisical design for the packages. Please comment it.
The main goal of redesign is to use Python distutils package.

pygccxml_dev/
|    |----setup.py
|    |----docs/
|    |    |----apidocs/
|    |----pygccxml/
|    |    |----declarations/
|    |    |----parser/
|    |    |----utils/
|    |----unittests/
|    |    |----data/
pyplusplus_dev/
|    |----environment.py #containes paths to boost  and pygccxml
|    |----setup.py
|    |----docs/
|    |    |----apidocs/
|    |    |----examples/
|    |    |----tutorials/
|    |----pyplusplus/
|    |    |----code_creators/
|    |    |----code_repository/
|    |    |----decl_wrappers/
|    |    |----file_writers/
|    |    |----gui/
|    |    |----_logging_/
|    |    |----module_builder/
|    |    |----module_creator/
|    |    |----scripts/
|    |    |----utils/
|    |----unittests/
|    |     |----data/
|    |     |----generated/
|    |----examples/
|    |    |----pyboost_dev/
|    |    |    |----setup.py
|    |    |    |----pyboost/
|    |    |    |    |----date_time/
|    |    |    |    |    |----generated/
|    |    |    |    |----....
|    |    |----pyeasybmp_dev/
|    |    |    |----setup.py
|    |    |    |----environment.py
|    |    |    |----pyeasybmp/
|    |    |    |    |----generated/
|    |    |----custom_code_creator/
|    |    |----unittests/
|    |----tutorials/
|    |    |----module_builder/
|    |    |----...

What do you think?

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Phisical (re)design

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> pygccxml_dev/
> |    |----setup.py
> |    |----docs/
> |    |    |----apidocs/
> |    |----pygccxml/
> |    |    |----declarations/
> |    |    |----parser/
> |    |    |----utils/
> |    |----unittests/
> |    |    |----data/
> pyplusplus_dev/
> |    |----environment.py #containes paths to boost  and pygccxml

What is this file used for?

> |    |----setup.py
> |    |----docs/
> |    |    |----apidocs/
> |    |    |----examples/
> |    |    |----tutorials/
> |    |----pyplusplus/
> |    |    |----code_creators/
> |    |    |----code_repository/
> |    |    |----decl_wrappers/
> |    |    |----file_writers/
> |    |    |----gui/
> |    |    |----_logging_/
> |    |    |----module_builder/
> |    |    |----module_creator/
> |    |    |----scripts/

Currently, this directory is not a sub-package and the files in this 
directory are not meant to be imported. That's why I'd suggest to move 
this directory up one level.

> |    |    |----utils/
> |    |----unittests/
> |    |     |----data/
> |    |     |----generated/
> |    |----examples/
> |    |    |----pyboost_dev/
> |    |    |    |----setup.py
> |    |    |    |----pyboost/
> |    |    |    |    |----date_time/
> |    |    |    |    |    |----generated/
> |    |    |    |    |----....
> |    |    |----pyeasybmp_dev/
> |    |    |    |----setup.py
> |    |    |    |----environment.py
> |    |    |    |----pyeasybmp/
> |    |    |    |    |----generated/
> |    |    |----custom_code_creator/
> |    |    |----unittests/
> |    |----tutorials/

What's the difference between docs/tutorials and tutorials?

> |    |    |----module_builder/
> |    |    |----...
> 
> What do you think?

Apart from the scripts directory, everything else looks fine to me.

- Matthias -

Re: [pygccxml-development] Phisical (re)design

[Roman Y. <rom...@gm...>]

On 4/18/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > pyplusplus_dev/
> > |    |----environment.py #containes paths to boost  and pygccxml

pyplusplus unit tests have external dependencies: boost libraries,
scons, location
of header files. This file should contain this information. I don't
like this approach.
The second approach I considered was environment variables - I hate
it. So I am going
with the first one. If you have better idea, and obvious you do, then
share it :-)

> What is this file used for?
> > |    |    |----scripts/
>
> Currently, this directory is not a sub-package and the files in this
> directory are not meant to be imported. That's why I'd suggest to move
> this directory up one level.

May be I missed that, so scripts will sit in the same directory where setup=
.py?

\>
> What's the difference between docs/tutorials and tutorials?
>
> > |    |    |----module_builder/
> > |    |    |----...

I want to create full separation between code and documentation.

docs directory contains documentation for whole project, including
examples, tutorials and
whatever.

All other directories contains code.

> Apart from the scripts directory, everything else looks fine to me.

I have question. pyplusplus depends on other software: boost, EasyBMP,
TnFOX and I can
add something in the future. I expose whole functionality found in
that libraries, except TnFOX ) to Python. So, those packages become
useful and valuable on their own.

How I should manage ( location within directory tree, for example )
those 3rd party libraries?

> - Matthias -


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Phisical (re)design

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> On 4/18/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>>> pyplusplus_dev/
>>> |    |----environment.py #containes paths to boost  and pygccxml
> 
> pyplusplus unit tests have external dependencies: boost libraries,
> scons, location
> of header files. This file should contain this information. I don't
> like this approach.
> The second approach I considered was environment variables - I hate
> it. So I am going
> with the first one. If you have better idea, and obvious you do, then
> share it :-)

Having some sort of config file for the unit tests is ok. The question 
is, if this file should be under cvs control or not. Personally, I think 
it should not be in cvs because the contents of that file depend on the 
user's environment and every user who wants to run the unit tests needs 
a different file anyway.

>> What is this file used for?
>>> |    |    |----scripts/
>> Currently, this directory is not a sub-package and the files in this
>> directory are not meant to be imported. That's why I'd suggest to move
>> this directory up one level.
> 
> May be I missed that, so scripts will sit in the same directory where setup.py?

That's what I would do. (You may put it into some other directory if you 
want, the point is just that it is not inside the 'pyplusplus' directory)

>> What's the difference between docs/tutorials and tutorials?
> 
> I want to create full separation between code and documentation.
> 
> docs directory contains documentation for whole project, including
> examples, tutorials and
> whatever.
> 
> All other directories contains code.

ok, I see.

> I have question. pyplusplus depends on other software: boost, EasyBMP,
> TnFOX and I can add something in the future. 

When you say 'pyplusplus' you obviously mean the entire contents of the 
cvs repository, right? (whereas when I read 'pyplusplus' I only think of 
the actual Python package (including pygccxml))
The above are not required for users of pyplusplus who create their own 
bindings. It's only required if someone wants to run the examples you 
provided (or if someone really wants those libraries in Python).

> I expose whole functionality found in
> that libraries, except TnFOX ) to Python. So, those packages become
> useful and valuable on their own.
> 
> How I should manage ( location within directory tree, for example )
> those 3rd party libraries?

Is the main intention of those bindings to serve as an example for 
pyplusplus or to create bindings that are really meant to be used on 
their own (and that are maintained by yourself)?
In the former case I would suggest to leave them in an examples 
directory and in the latter case I would argue that they don't belong 
into the pyplusplus repository and you might instead consider 
registering one or more new SF projects for them.

- Matthias -

Re: [pygccxml-development] Phisical (re)design

[Roman Y. <rom...@gm...>]

On 4/19/06, Matthias Baas <ba...@ir...> wrote:
> Having some sort of config file for the unit tests is ok. The question
> is, if this file should be under cvs control or not. Personally, I think
> it should not be in cvs because the contents of that file depend on the
> user's environment and every user who wants to run the unit tests needs
> a different file anyway.

1. I think, that this file should be svn( :-) ) control:
    every user developer should see what he/she should change in order
to run unit tests

2. I think, that this file will contain my and your settings, so you
will be able to run
    unit tests too.

> >> What is this file used for?
> >>> |    |    |----scripts/
> >> Currently, this directory is not a sub-package and the files in this
> >> directory are not meant to be imported. That's why I'd suggest to move
> >> this directory up one level.
> >
> > May be I missed that, so scripts will sit in the same directory where s=
etup.py?
>
> That's what I would do. (You may put it into some other directory if you
> want, the point is just that it is not inside the 'pyplusplus' directory)

I've got it. Thanks

> > I have question. pyplusplus depends on other software: boost, EasyBMP,
> > TnFOX and I can add something in the future.
>
> When you say 'pyplusplus' you obviously mean the entire contents of the
> cvs repository, right? (whereas when I read 'pyplusplus' I only think of
> the actual Python package (including pygccxml))
> The above are not required for users of pyplusplus who create their own
> bindings. It's only required if someone wants to run the examples you
> provided (or if someone really wants those libraries in Python).
>
> > I expose whole functionality found in
> > that libraries, except TnFOX ) to Python. So, those packages become
> > useful and valuable on their own.
> >
> > How I should manage ( location within directory tree, for example )
> > those 3rd party libraries?
>
> Is the main intention of those bindings to serve as an example for
> pyplusplus or to create bindings that are really meant to be used on
> their own (and that are maintained by yourself)?

The second one.

> In the former case I would suggest to leave them in an examples
> directory and in the latter case I would argue that they don't belong
> into the pyplusplus repository and you might instead consider
> registering one or more new SF projects for them.

I will think about this.

> - Matthias -


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/