Re: [CEDET-devel] support for external parsers
Brought to you by:
zappo
From: Jed B. <je...@59...> - 2011-04-14 12:37:37
|
On Wed, 13 Apr 2011 19:28:57 -0400, "Eric M. Ludlam" <er...@si...> wrote: > This is because I don't build Linux myself, and put this together merely > trying to get some basic smart completion going. The entire "how to > compile/debug" feature set wasn't implemented for the linux project > type. The same is true for the emacs project type. I don't develop > emacs, but just put the project together for basic completion. > > What this means in both cases is that the "-I" type arguments is > represented by the method ede-expand-filename-impl for each project > type, where when Emacs looks up where some #include might be. These > contain short cuts based on file extension. > > This means someone could explicitly code in the ones that I missed when > I first put this project together. > > For ede-linux one could assume that hdr-arch matches the current arch, > or it could be added via the "configurations" entry for the linux > project class. I only expanded on this concept recently in the android > branch which needed this, but the basic infrastructure has been there a > long time. > > In ede-android.el in the android branch in bzr, these two lines were > added to initialize-instance for the project: > > (oset this configurations '("debug" "install" "release")) > (oset this configuration-default "debug") > > For ede-linux, you could open some configuration file, and derive the > list of possible configurations. Changing the configuration (made > easier on my android branch via menu item) could then affect either the > include path, and the build command. This is very helpful, thanks. I'll check out your android branch. A natural extension would be to check the filesystem using the project's conventions for handling configurations (e.g. make the configuration list be all X such that X/include/fooconfig.h exists). > This could be handled with the "configurations" slot in all projects, > but this was never expanded on beyond some basic support in the project > type that creates Project.ede files. > > In order to "update analysis", this would mean that if the default > configuration changes, that would trigger all the semantic database > tables related to your project to get flushed and all open buffers > reparsed after settings had changed. It also means that > ede-expand-filename-impl would refer to the configurations option. When switching from configuration X to Y, would it be possible to save the old database so that you could have it back when you switched back to X later? > If by "configurations" you mean that one project is configured with > three different independent features, then the same basic thing of > flushing caches would need to happen, but detection is harder. The > resultant configure output would need to be parsed to get the results. > If all those results are in "config.h" or some such, then it could be as > easy as tracking that file for differences and causing the flush to > occur then. Since config.h would be targeted as a source of macros not > much else would need to be done. This is indeed the case I care most about. All the configure results go into config.h, but different -I flags will be also be present and the source contains #ifdef USE_FOO # include <foo.h> #endif Configuration X might not defino USE_FOO and provides no -I flag, but configuration Y defines USE_FOO and sets -I/path/to/foo/include . > > I think this is a relatively basic example, but I know it would take me > > lots more than half an hour writing ELisp to get "reasonable" > > functionality. What I have written so far is an unhappy partial > > solution. > > If you are trying to write a project for a very specific project (like > Linux), encoding the include path and macro source header is not that > hard. If you are trying to get generic support for any autoconf > project, that will be much harder. Since you are also trying to support > the handling of configurations, that will increase the complexity since > you need to write parsers for the files that contain the configuration. > > At this point I'm not quite sure what you are trying to do so it is hard > to give some good advice. Are you trying to improve the Linux support, > add generic autoconf support, or support one very specific project that > uses autoconf? There are half a dozen projects that I either work on directly or call as a library and need to dig into because of sparse/inaccurate documentation. These all have roughly the structure described in the last post, despite using three quite different build systems: 1. automake with optional features managed like if PARALLEL SUBDIRS += parallel AM_CPPFLAGS += -I$(srcdir)/parallel endif 2. cmake (fairly standard, optional features/dependencies) 3. custom python build system, similar model for multiple configurations If I had something working well for any one of these, it would be pretty straightforward to extract the common bits so that each new project style (of the three above) could be 10 or 20 lines of whatever was unique. This does not include parsers for various configuration system programming languages which seems like a big task and I'm not sure is worthwhile at all (hence my thoughts on snooping the compilation process instead). In the cases I'm thinking of, I think it would be acceptable to just manually specify any project-specific variable names to extract from certain generated makefiles. Thanks again. |