Re: [anjuta-devel] RFC: Symbol-db future

["Johannes Schmid" <jhs jsschmid de>]

Hi Sébastien

> I can imagine that another language (vala ?) could directly use C
> library and so use pkg-config. On the other hand, I don't think a
> project written in a language not able to use C library will use
> pkg-config. Anyway, I don't care that much if it's done in the language
> support plugin.

Vala will definitly use it as it needs the C headers for building. I am
not sure how the introspection system of python and javascript work but I
would assume that they don't need any development libraries installed at
all.

> > The method could as well be
> > called add_files(). The symbol-db plugin will have to check anyway, if
> > those files are in the database already. Sorry for being misleading
> > here.
>
> Ok, so I think a method add_files will be better then. If we parse
> include, we don't have package anyway.

The advantage of add_package is that the symbol-db can display a more
detailed progress bar (Scanning x of y (xy%) of gtk-3.0). Anyway, I am
fine with add_files.

> > And again, project-manager shouldn't do C/C++ specific things.
>
> I'm agree but a pkg-config package represents a C library so it's
> already specific to C. Most part is in the autotools backend not in the
> project manager plugin. The autotools is designed for C project so I
> don't see a problem to have C specific things here.

Partly agreed that pkg-config itself is very C specific but it is
something that must be done in the autotools backend anyway. Autotools
works pretty good for almost any of the supported languages though and it
is standard in GNOME anyway.

> > * symbol-db will scan all the include dirs we have with pkg-config
>
> Ok, do you plan to add in the symbol-db database header files which are
> not belonging to any package ? It's the case for standard C header file
> or all libraries which don't have a specific directory.

I think we would add those with add_files(), too.

> Ok, so the difference is that I have proposed to save, in addition, the
> header files included in each source file. This will avoid to run gcc
> each time, but if it's fast enough we don't care.

While I am not entirely sure I think keeping the C -> headers mapping in
the database just makes it more complicated. Seems like gcc -MM doesn't
really take much time so I would rather like to keep the database
lightweight.

Thanks for your comments,

Johannes