Re: [anjuta-devel] Scons Support in Anjuta

[Sébastien Granjoux <seb sfo free fr>]

Hi Abderrahim,

Le 28/08/2010 19:01, Abderrahim Kitouni a écrit :
> Thanks for your thorough explanation, I think I understand (and like)
> the idea. I still have some concerns with the implementation (see
> below).

That's ok to change some things in the current interface if you have a 
better idea.


> Although I don't like the free_node function, I'm fine with this
> interface (now that I know it's only 6 methods :-)).

What don't you like in the free_node function ? I think it's necessary 
if we want to extend the node to add backend's specific data.


> So this means that e.g. to add a source file to a target, new_node is
> called to create the source file node, then it's added to the target
> node using AnjutaProjectNode API and then save_node is called. Right?

Exactly.


> I'm not sure I understand the whole property stuff, could you elaborate
> a bit?

Sure, I haven't explained how it's working in my previous mail.

Like a AnjutaProjectNode*, it is a GList * with a 
AnjutaProjectPropertyInfo structure as data. Again, the 
AnjutaProjectPropertyInfo structure can be extend by the backend to keep 
specific informations.

Each node has a pointer to a AnjutaProjectProperty element. As a 
AnjutaProjectProperty is a GList, it can be NULL if the node has no 
property.

Then, something really special about properties is that when a node is 
created the pointer on AnjutaProjectProperty point to a list of all 
possible properties. This properties contains the default value for all 
properties. This list is never modified, so it is normally a static 
list. By example, the autotools plugin uses the same list for all group 
nodes and only a few list for different kind of targets nodes.

So each property is defined by the address of the AnjutaProjectProperty 
in this list. By example a target item will have a AnjutaProjectProperty 
corresponding to CFLAGS and if you want to set CFLAGS you need to use 
the address of this element to set it.

When a node has only default values for all its property, it has a 
pointer to this static list named properties. Now when when there is one 
or more properties which have a custom values, a new 
AnjutaProjectProperty element is created (by the backend) for each and 
put in a list. And this list replace the static list in the properties 
member of a node. The static list of all possible properties is still 
accessible through the override field of the new property which point to 
the original property element.

If an AnjutaProjectProperty element has the member orverride to NULL, it 
is part of a default property list and is static. Else it is a "real" 
property and the original property node is pointed by override.

I hope it's clear enough.


> IIUC, it's for information that's not sources but is attached to
> targets like CFLAGS and such?

Yes.


> > * get_root. I think it's not needed. You create yourself the root node
> > with new_node to load it. So you just need to keep it.
> Who is "yourself"? You're talking from the project manager point of
> view?

Yes, "yourself" is an user of the project interface. For Anjuta, 
normally it is the project manager plugin.

> > The AnjutaProjectNode and AnjutaProjectProperty are not GObject but
> Why not? ;-) I think a GObject is more bindings friendly (and by
> bindings, I mean GObject-introspection) and I beleive the implementation
> could be cleaner. new_node would still be needed (or alternatively a
> function that would return a GType for a given node type, whichever
> feels cleaner).

Because a GObject is bigger (not that much I think let's say 2 or 3 
times) and much slower to create (probably 10 times). Then, I need to 
rewrite several GNode function, next, previous, parent, child... and the 
basic GObject function, get_type, init, finalize...

I'm not sure it's will be easier for bindings. By example, I think it's 
not possible to create a GObject in a plugin if we use libpeas and I 
suppose this limitation comes from the bindings.

Anyway, I haven't taken bindings into account for choosing this,  if 
there are some issues, this can be changed. But I think a GObject is not 
always better, it depends on its use.


> > It means that the project backend has to create a C structure
> > representing the project using AnjutaProjectNode.
> That's the problem I'm facing right now (or rather, I was facing when I
> last touched this). You have no way to create an AnjutaProjectNode, it
> doesn't have a _new function.

I haven't created one because it was easy to create in C but I can write 
a generic one see below.


> The problem is that you cannot really allocate "more than the minimum
> needed" when using e.g. Python (and even in Vala it does require some
> "clever hacks")

I don't think it will be a problem in Python or Vala or rather I think 
it can be solved because I think it's less hack than GObject.

> [1]. I thought about working around this by keeping a
> hashtable in the plugin for extra data, but there is the problem of not
> being able to create an AnjutaProjectNode.

I can think about 3 solutions for this issue.

1. We write a anjuta_project_node_new that is creating a GNode having an 
AnjutaProjectNodeData as parameters. Nothing difficult here and that's 
fine for the interface. But then you probably need additional 
information in the backend associated to each node, so you can create a 
hash table with the node address as a key to keep whatever you want.

2. Better, the anjuta_project_node_new has an additional gpointer as 
argument and create a AnjutaGenericProjectNodeData which is an 
AnjutaProjectNodeData and a gpointer. In this case you have to allocate 
all your specific data in a block or memory and give the pointer to the
anjuta_project_node_new function. So you don't need the hashtable anymore.

3. Another possibility is add a sizeof argument to the generic 
anjuta_project_node_new and allocate additional memory (more than just 
the size of a gpointer) and put all your specific data here. I'm not 
sure it's possible though.


> This one seems nice, removing all assumptions about the underlying
> system. The backend can decide for example that packages are added
> directly to sources rather than to a module.

Yes, comparing to the old interface, the new one is more generic.


> > the save_node function which is really difficult to do.
> Why would it be difficult? (Unless you mean writing to a hand-editable
> file, which is a problem of its own).

For exactly this reason. Makefile.am and configure.ac are hand-editable 
files. I think scons are hand-editable too, even worst it's a complete 
programming language.


> I don't think GMarkupParseContext has binding everywhere (almost every
> language has its own "xml subset" parser) and is introspection-friendly
> (the fact that it needs a struct full of callbacks isn't really nice),
> but being in GLib, it cannot depend on GObject.

Ok, let's say GRegex then or any other object in GLib which is not a 
GObject.


> I think a simple solution to this is to make AnjutaProjectNode *really*
> opaque (rather than a typedef of GNode), add new and free functions, and
> register it as a boxed.  I don't know if this will affect the existing C
> backends, but if they really need the "allocate more than the minimum
> memory" trick, then it would be best to just use a GObject (or maybe an
> extra user_data field will do).

I think it's not a problem to make it really opaque.

I think it can be registers as boxed but I'm not sure it's even needed. 
I think it can be considered as a simple pointer as the life of the node 
is controlled by the backend.

The trick used in C, it's not necessary, it's just easier in C.


> Seems we're getting really close to something useable :-)

Fine.


Regards,

Sébastien