Re: [CEDET-devel] support for external parsers
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2011-04-13 23:29:05
|
On 04/13/2011 10:34 AM, Jed Brown wrote: > On Tue, 12 Apr 2011 20:46:11 -0400, "Eric M. Ludlam"<er...@si...> wrote: >> Using basic EDE configurations is indeed a pain to setup. Very common >> build types are supported well, such as Linux and Emacs builds. It is >> impossible to create a generic way to derive include paths and such. >> Even with the suggested hacks of running Make and parsing the command >> line is problematic due to the wide array of compilers and build systems. > > A compiler wrapper still seems like it could be more robust (especially > if you're committing to using clang for semantic analysis already) > because it's build system agnostic and guaranteed to be > current. Otherwise, you have to extract or reproduce the dependency > graph from the build system so that correct headers are pulled in. > >> Fortunately, it isn't too hard to write your own EDE project type (just >> look at EDE Linux for example) that will look into the right spot to >> derive such things. Thus, if you have some special kind of project you >> work on a lot, creating the new EDE project may take a half hour or so, >> which is worth it. Unless you don't know Emacs Lisp of course, which is >> the big barrier to entry on this technique. > > I think you need significant familiarity with EDE, not just ELisp for > this. And I still think it's pretty hard. > > Linux is quite simple due to lack of dependencies, but as far as I can > tell, ede-linux.elemacs is not aware of the top level Makefile's > > LINUXINCLUDE := -I$(srctree)/arch/$(hdr-arch)/include -Iinclude \ > $(if $(KBUILD_SRC), -I$(srctree)/include) \ > -include include/generated/autoconf.h > > which becomes part of KBUILD_CPPFLAGS. > > Since I don't see any special handling for autoconf.h in ede-linux.el, I > assume that semantic will know nothing of those definitions. I also > don't see how to inform it that I'm interested in a different arch, for > example when switching "make ARCH=x86_64" to "make ARCH=arm" (headers > are resolved differently and different sources are compiled so > semantic-ia-fast-jump should send me to quite different places). 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. > Perhaps you could explain (or point to documentation/examples) how to > handle the following. > > Stardard autoconf project > > /Project/Makefile.in > /Project/configure.in > /Project/include/... > /Project/src/... > > which we build from /Project/build-*/ using > > ../configure --with-{32,64}-bit-indices --with-scalar-type={real,complex} --with-foo-dir=/Foo{1,2,3} > > which creates /Project/build-*/{Makefile,include/config.h}. Each > implementation of the Foo library has the same API, but a different ABI > (e.g. a handle may be represented using a pointer to incomplete type in > one implementation, but an integer in another). Some of the builds are > configured with an optional dependency --with-bar-dir=/Bar which > means building different files in the current Project. Autoconf projects that also use automake have their own project style in "project-am", unfortunately this doesn't support detecting configurations as you suggest above. > How would you handle switching between build configurations so that > analysis is updated after switching (e.g. Bar_* symbols are only > completed when on a build where that package was enabled, jumps go to > the correct place) and changes to Makefile.in (e.g. adding a -I/path) > are used without having to mirror them in Emacs Lisp? Note that build > configurations come and go over time (e.g. to reproduce a problem in a > support request), I want to switch with something as easy as setting > compile-command to "make -C /Project/build-13". 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. 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. > 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? It is possible that ede-generic will get you part-way there, and that a couple additions to it will solve some of these problems. I also suspect that my changes to support android should probably be merged back into trunk to help support configuration concepts. A major issue is that I don't write code anymore (except for toys here and there) and project management tooling is something most Emacs uses don't care for. Thanks Eric |