Hi Nicolai,
Thanks for the example, which is new to me, and patch! I always like
patches.
EDE has an interesting bit of history here in that it started as one
project one directory, with a tree of projects, much the way every
Makefile I'd ever used worked. Much later, some project types that only
have 1 build at the top of a tree started getting supported.
This case is a bit different in that any project within a tree could
refer to some other directory full of files. If the "src" directory in
your example has no Makefile.am in it, EDE might not even think to look
up one directory for a project referring to your files.
The nature of your patch, with new utilities in core EDE being used by
makefile-am.el is a good strategy. I think, however, you can use the
method ede-buffer-mine to ask some project or target if some buffer
belongs to it. In turn from there, could use use `ede-find-target' to
identify the project or target a file belongs to?
If those didn't work, you may just need to tweak ede-buffer-mine to
account for the extra level of directory, and that can be done entirely
in project-am.el.
I am still in the process of fixing the EDE security issue posted
recently and trying to make some releases, so can't work on this
directly or check in patches for a little while, but after that, this
seems like a great idea to support.
Thanks
Eric
On 12/20/2011 06:30 AM, Nicolai Stange wrote:
> Hi everybody,
>
> I've got some Autotools project which contains a Makefile.am like this:
>
> test_SOURCES = src/foo.c lib/bar.c
>
> Unfortunately, EDE can't assign these files to the project when visiting
> them (i.e. `ede-object' is set to nil for these buffers).
>
> I'm very new to Emacs Lisp/Cedet (actually I got my first experience by
> trying to fix this).
>
> Anyway, the reason seems to me that
> `ede-initialize-state-current-buffer' [ede.el] used to call
> `ede-directory-get-open-project' [ede-files.el] with
> `(default-directory)' as argument. Of course, in '(default-directory',
> there is no Makefile.am.
>
> My first attempt to fix this (see attached diff) is to introduce
> `ede-file-get-open-project' that gets called with `(buffer-file-name)'
> from `ede-initialize-state-current-buffer' now. This functions looks
> into all targets of all projects and searches for one that contains that
> file. For this, it uses the new methods `ede-file-in-target-p' of
> `ede-target' and `ede-file-in-project-p' of `ede-project' (both in
> ede-files.el).
>
> However, I had to replace some parts in
> `ede-initialize-state-current-buffer', especially the call to
> `ede-buffer-object' [ede.el], because this guy calls
> `ede-current-project' [ede.el] and this in turn ends up in a directory
> based search.
>
> [Remark: It could be, that `ede-buffer-object' suffers from a misdesign
> in that it actually serves two purposes: A quick grep shows
> that the optional BUFFER argument is only given in that call
> from `ede-initialize-state-current-buffer' that I
> replaced. Maybe all other calls appear in a situation where
> `ede-object-project' has already been set for that buffer (and
> thus gets returned through `ede-current-project'?). But as said
> above, I'm in lack of the big picture, it just smells to me like
> there's a possibility.]
>
> So if you agree that Autotools projects like the one described above
> should be supported by Cedet, there is more work to do: At least every
> location calling `ede-directory-get-open-project', `ede-buffer-object'
> and `ede-current-project' should be checked whether it still does what
> it is supposed to do. The attached diff is only meant to serve as a
> starting point, it is tested only a little bit with my existing
> Autotools project (it is very likely to break things/not being
> complete: e.g. running of compiled targets ...).
>
> Finally, I modified project-am.el to get the compilation commands
> working (the reason why I initially started with this).
>
> I look forward to read your comments
>
> Best,
>
> Nicolai
>
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
>
>
>
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
|