GNOME Bugzilla – Bug 623735
Move pkg-config symbol parsing to language-support-cpp-java
Last modified: 2011-03-05 09:22:36 UTC
The detection of pkg-config packages and the manual preferences should be part of the language-support-cpp-java plugin as it is only interesting for C and C++. Python, Javascript use the "import" keyword to import packages from their system search path instead. So what we should do is: * Move the pkg-config files detection from symbol-db to language-support-cpp-java (fixing bug #618119 on the way) * Add following interface to symbol-db: /* ianjuta_symbol_manager_add_package: * @pkg-name: Name of the package to scan. Should be the name given by pkg-config * @version: Version of the package * or by the language implementation (Python, Javascript, etc.) * @files: A list of GFile's to scan for this package * * Reads the package files into the database */ void ianjuta_symbol_manager_add_package (const gchar* name, const gchar* version, const GList* files) /* ianjuta_symbol_manager_activate_package: * @pkg-name: Name of the package to activate * @version: Version of the package * * Activates the package for searches in the global symbol database. * * Returns: TRUE if the package was loaded (or will be loaded once scanned). * FALSE if the version given was newer than the version in the database or the * package was not found. In this case, add_package() should be called. */ /* ianjuta_symbol_manager_decativate_package: * @package: name of the package * * Deactivates the package if it was found. If package is NULL, deactivate all * packages */ void ianjuta_symbol_manager_decativate_package (const gchar* package); I added the version field to avoid expensive time checks for all package files. The version can be easily queried from pkg-config and it should be possible to store it in the database.
* Of course, move the preference options from symbol-db to language-support-cpp-java (Tab: autocompletion). This will also reduce confusion for other languages that do not support this mechanism.
One useful improvement would be to allow adding individual file or directories. Some libraries using pkg-config doesn't put their header files in a separate directory, in this case symbol is not able to find the header. Being able to add the header file manually would be an improvement. Then, all libraries not using pkg-config cannot be used by symbol-db, so having a way to add files and directories will help here too.
@jhs: you wrote in a recent mail that you're moving the symbol-db stuff into language-support-cpp-java. Are you coding something or should it be started?
I did some prototyping UI but no real coding. I would love if someone would start on that, especially the part of sorting out the packages mess in a way that gtk+ does just contain the gtk header files.
I'll focus on this bug now.
(In reply to comment #2) > One useful improvement would be to allow adding individual file or directories. > > Some libraries using pkg-config doesn't put their header files in a separate > directory, in this case symbol is not able to find the header. Being able to > add the header file manually would be an improvement. > > Then, all libraries not using pkg-config cannot be used by symbol-db, so having > a way to add files and directories will help here too. well, actually, from what I see, it's the external plugin that decides the name of the package and its source files. So your option is already included in the interface.
@jhs: I suppose that language-support-* plugins will take care of saving session_packages with anjuta_session_set_string_list (), and notify symbol-db to reactivate them when db is connected.
I've committed some more changes on sdb-core-trans branch. What is missing now: * a language-support-cpp-java api that automatically add_and_activate () the required packages (and their versions) on IAnjutaSymbolManager. * a way to detect what files are actually necessary to scan a package. GList files. * on symbol-db side: removing of symbol-db-system crap. I'll focus on this one, but I need help for the other two. I can also merge sdb-core-trans into master but we will loose completion for, say, GLib and Gtk symbols, so I think I'll wait a bit.
Thanks for all your work! > * a language-support-cpp-java api that automatically add_and_activate () the > required packages (and their versions) on IAnjutaSymbolManager. That should be rather trivial with ianjuta_project_manager_get_packages() but I am not sure how we manage the session correctly. Is the symbol-db API for adding packages that are already parsed expensive? > * a way to detect what files are actually necessary to scan a package. GList > files. That's trickier and involves some pkg-config magic and maybe some (educated) guessing. > I can also merge sdb-core-trans into master but we will loose completion for, > say, GLib and Gtk symbols, so I think I'll wait a bit. I think we should postpone that until 2.32 is out because it is quite likely that we break things in between and we shouldn't do that so close to a release. I will be a big improvement for 3.0 though.
(In reply to comment #9) > Thanks for all your work! > > > * a language-support-cpp-java api that automatically add_and_activate () the > > required packages (and their versions) on IAnjutaSymbolManager. > > That should be rather trivial with ianjuta_project_manager_get_packages() but I there's an addon to do into project_manager too, the versions aren't managed now. Otherwise the ianjuta_project_manager_get_packages () suits good. > am not sure how we manage the session correctly. Is the symbol-db API for > adding packages that are already parsed expensive? > Actually the add_package tries to add an entry on 'project' and then process all files. The quickest sequence is isymbol_manager_activate_package () and then isymbol_manager_add_package (). The former checks if a package is already loaded in an hash table of the session. If not found it'll check if present on db. If it's not there too then return false. The function add_and_activate () should be launched once (for instance at the first population) and is a convenience function for calling first add_package then activate. > > * a way to detect what files are actually necessary to scan a package. GList > > files. > > That's trickier and involves some pkg-config magic and maybe some (educated) > guessing. > yep. Shouldn't project-manager be useful here? For instance it can populate the lists, or a function like ianjuta_project_manager_get_packages () is nonsense into project-manager, if we have to implement our own parser. That get_packages () function will work only for c/c++ projetcs. We may rename it to ianjuta_project_manager_get_c_cpp_packages (). > > I can also merge sdb-core-trans into master but we will loose completion for, > > say, GLib and Gtk symbols, so I think I'll wait a bit. > > I think we should postpone that until 2.32 is out because it is quite likely > that we break things in between and we shouldn't do that so close to a release. > I will be a big improvement for 3.0 though. ok no problem for me, but please note that I've cleaned a lot of code into symbol-db-core that will: 1. be merged after the release but 2. at the same time will keep me 'blocked' to fix some stuff on symbol-db otherwise the merge between master and sdb-core-trans will fail.
On my side, I'm still working in the newproject branch. I'm now more or less able to add source files (one is working fine, two doesn't work fine), I think this will be ready for the 3.0 release. I think, I need to be ready to merge the newproject branch into master just after the 2.32 release so we can have a complete cyle to stabilize all this. Or should we already start in a common branch ? In the newproject branch, I have several crashed due symbol-db, I think because the interfaces is a bit different. I sent notification even when the project is not completely loaded because I'm taking care of loading all packages and it takes a lots of time. For the moment, if I see a crash due to symbol-db, I don't take care of it but it becomes quite annoying. I think it's better to move pkg-config stuff in the project manager as it's really part of the project format not the language. Currently, you can get a list of packages and corresponding sources using ianjuta_project_manager_get_children. The modules, packages and sources files appears likes groups, targets and sources in the current project manager. Then, for some language the "packages" are part of the source files, by example import directive in python. So I think it makes sense to allow the language support plugin to send packages to symbol-db. I think it could be done in the C language plugin for pkg-config as a temporary solution to check that the interface is working.
One thing forgotten. Currently we don't have issue with the import directive with python completion because this doesn't use the symbol-db plugin. It uses ropes which is taking care of everything. I think it would be better to use symbol-db plugin, like with C but it will be much more difficult.
I've just merged master into sdb-core-trans and fixed some conflicts and I'm ready to re-merge into master and continue the development there. I've also seen an-hundred-mails-long thread about project-manager (which I hadn't time to read). How the things there, if you can summarize them here? @seb: you say that it would be better to have pkg-config stuff inside pm, but I don't remember if we already talked about this on IRC with jhs. In sdb-core-trans the pkg-config is inside langauge-support-cpp-java, which I think is ok.
(In reply to comment #13) > @seb: you say that it would be better to have pkg-config stuff inside pm, but I > don't remember if we already talked about this on IRC with jhs. > In sdb-core-trans the pkg-config is inside langauge-support-cpp-java, which I > think is ok. I don't care if pkg-config packages are handled by the language-support-cpp-java plugin. But I think it's needed to be able to add an remove packages in a project. This is something not obvious to implement and I think it's better to do it in the project manager.
Ok. What's your plan on adding them? Actually on language-supporr-cpp-java I'm adding packages names without the list of the files themselves: I'm calling IAnjutaSymbolManager new interfaces as http://git.gnome.org/browse/anjuta/tree/libanjuta/interfaces/libanjuta.idl?h=sdb-core-trans#n6073 I'm also using on lsp-cpp-java the widget anjuta-pkg-config-chooser for the preferences. I suppose that project-manager should public an api as 'give_files_for_package (const gchar *package_name)', so that lsp-cpp-java can query it, retrieve the files list and pass them to symbol-db interface. What do you say? @jhs: writing here instead of mailing list is better IMHO because everything is tracked and easily reachable.
(In reply to comment #15) > Ok. What's your plan on adding them? > Actually on language-supporr-cpp-java I'm adding packages names without the > list of the files themselves: I'm calling IAnjutaSymbolManager new interfaces > as > http://git.gnome.org/browse/anjuta/tree/libanjuta/interfaces/libanjuta.idl?h=sdb-core-trans#n6073 > > I'm also using on lsp-cpp-java the widget anjuta-pkg-config-chooser for the > preferences. > I suppose that project-manager should public an api as 'give_files_for_package > (const gchar *package_name)', so that lsp-cpp-java can query it, retrieve the > files list and pass them to symbol-db interface. Currently, I'm still changing the project interface. But you already have all modules as children of the root node, packages as children of each modules and header files (source) as children of all packages. Then there are functions to get all children of a project node and get the type of the node (root, source, target, package or module).
(In reply to comment #16) > > Currently, I'm still changing the project interface. But you already have all > modules as children of the root node, packages as children of each modules and > header files (source) as children of all packages. > that's great news > Then there are functions to get all children of a project node and get the type > of the node (root, source, target, package or module). ok. I suppose it'd be better to wait for you to merge into master before proceeding with this bug.
I merged the system-db-refactor branch which basically fixes this: * pkg-config specific code moved to libanjuta * C/C++ specific code moved to language-support.