Re: [pygccxml-development] code_repository package

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

On 9/20/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >>>> How do I influence whether a file is considered a system header or not?
> >>> In creator_t, you add your header file using add_system_header API
> >> I suppose the header should only be created when it is required, right?
> >
> > file_writers package will do that for you.
>
> How does it do that?

writer_t class defines write_code_repository method. It is a respnocibility of
derived file writers to call this function.

>
> The responsibility of a code creator object is to create a piece of C++
> source code that will be written into one or more output files, right?
> Now my actual question probably boils down to the following question:
> Whose responsibility is it to make sure that the code that was generated
> by a particular code creator object can also be compiled without errors?

File writer + code creator. File writer answer the question: where to put the
code, while code creator "what code to put". creator_t defines
"logical" place of the code creator, by placing it in the right place
within the tree. File writers insure that the "logical"
place of code creator is preserved.

My advice: implement your feature as is all code would be written in
single file.
Only then think about multiple files.


> >> Just to see if the file gets written or not I called add_system_header()
> >> and adopt_creator() on every call to visit_member_function(), but then I
> >> get a huge list of identical include statements in the generated files.
> >
> > I don't fully understand what you are doing here.
>
> I was just doing what you were suggesting earlier, i.e. to call
> add_system_header() to have Py++ write a particular header from the code
> repository package. This did work but the file was nowhere included, so
> I added an "include" code creator using adopt_creator() on the root node
> (I was peeking at the array_1 stuff to see how it is done). But as I was
> doing that in every call to visit_member_function() the file got
> included again each time resulting in a lot of duplicate lines.

Okey. You will have to prevent this and I think you already understand
how to do this
or already did. Am I right?

> >> What I would actually like to do is to add the "include" code creator to
> >> the associated_decl_creators list of the corresponding class so that the
> >> include only shows up in the file where it is needed. But how can I
> >> check whether the file was already included or not?
> >
> > If we talk about system header than you can ask module_t code creator
> > ( creator_t.__extmodule ) is_system_header.
>
> ok, this is what I'm doing now and which does work for now. But this
> makes the include file a "project wide" include file. How should I do
> this check if I would only like to add the include code creator to the
> associated_decl_creators list? (so that it only gets included where it
> is required?)

It is not possible. I tell you more, it will not be possible for few
next versions.
Py++ is missinig one concept - "bind" or "connect". Today user is not able to
"bind" between different declarations and different pieces of generated code.

Consider next cases:
* expose get\\set function as python properties
* expose begin\\end iterator as Boost.Python range
* add code "X" to the file, where declaration Y will be generated.
* register opaque type, when function has relevant call policy

I can continue the list, but I think you understand me. The small
refactoring I do on
code creators and file writers should improve (not fix ) the situation.

> >> I wonder why there is no specific API for managing include files that
> >> handles all those stuff? It appears to me that this would be quite a
> >> useful thing to have.
> >
> > Lack of time and low priority. Users learned to leave with "non
> > optimal" generated
> > code. I mean that all include appears in all header files. But they don't like
> > Py++, when it does not support the functionality they needed.
>
> That's not what I meant. I mean, even when the current functionality is
> exactly preserved, I would rather like to have an (internal) API that
> handles the details of how an include file is added to the output files.
> This is required at several places and it's not easy to understand how
> it is properly done. An additional benefit would be that it would pave
> the way for improving the handling of include files so that they could
> be set on a file-by-file basis.

I think I answered your question. In other words the problem is
"wider" and I want
to have 1 solution for it.


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