Hi,
Sounds like you have a good start on your EDE project.
Unfortunately, the generic EDE project assumes projects where every
subdir has a config file in it, and it then assembles the toplevel
project from all the subprojects. This would be a typical Make style
project where you might call make -C from your toplevel Makefile.
There are other projects that have only one config file at the top, and
all subdirs are assumed to be part of that project. This includes the
android, arduino, emacs, and Linux project types.
The problem with this kind of project, is you need to open a file at the
top-level to get it detected before opening files from subdirectories.
Easy to forget.
Anyway, the logic for doing that is in the load-type of the project
autoloader. You didn't create one since you used
ede-generic-new-autoloader. That doesn't return the new autoloader for
modification. You can, however, just copy that function and tweak it to
use your own load-type function.
Anyway, if you have some lisp skills, you can just splice in some
directory matching code against previously loaded projects of your type.
You can find examples in the android project type. I don't think
that's part of Emacs yet though, so you'd need to find it from the bzr
version.
There were a bunch of changes in the EDE project loading since CEDET as
found in Emacs. The trick I describe should work, but I'm not 100% sure
if the symbols are exactly the same. The emacs project type should have
some similar logic to use, though it uses tricks related to directory
names too.
Good Luck
Eric
On 05/11/2012 12:20 AM, sand@... wrote:
> The company I work for has a high-level build system that's intended to cover multiple underlying build systems (make vs. ant vs whatever). Let's call it "confoogure". The confoogure build system deals in terms of packages, defined by Config files. If your current directory---or any of your parent directories---has a Config file for the "Frobulator" package, you are "in" the "Frobulator" package, and so are your files. You can do various build tasks by running "confoogure-build" in the top-level package directory: "confoogure-build release", "confoogure-build test", etc.
>
> Right now, I have Emacs set up to do the following when loading a file:
>
> (a) Check whether there is a Config file in a parent directory
> (b) If there is, set the compile-command to be "cd ../..; confoogure-build" (where I go up enough directories to reach the Config file).
>
> I would like to get EDE to understand confoogure. If I can get Emacs to recognize that a given file or directory is managed by confoogure, then I should be able to build without going through the compile-command hack. Further down the line, I should be able to mine the Config file for metadata on what flymake should invoke, and where GNU Global should put its output files. But I'm having a hard time. What I have so far is:
>
> (require 'ede/generic)
>
> (defclass ede-generic-confoogure-package-project
> (ede-generic-project)
> ((buildfile :initform "Config"))
> "Generic Project for Confoogure packages.")
>
> (defmethod ede-generic-setup-configuration
> ((proj ede-generic-confoogure-package-project) config)
> "Setup a configuration for Confoogure package."
> (oset config build-command "confoogure-build ")
> (oset config debug-command "confoogure-build "))
>
> (defmethod project-compile-project
> ((proj ede-generic-confoogure-package-project)&optional command)
> (require 'compile)
> (let ((default-directory (oref proj :directory)))
> (compile (oref (oref proj config) :build-command))))
>
> (ede-generic-new-autoloader "edeproject-confoogure-package"
> "Confoogure Package" "Config"
> 'ede-generic-confoogure-package-project)
>
> As you can see from the require statement, I'm using the CEDET shipped with the Emacs24 pre-release. There are non-technical issues that make it easier to use the as-shipped files.
>
> The problem seems to be that EDE requires subprojects to function properly. Assume we have the following layout...
>
> MyPackage/
> Config
> bar.c
> src/
> foo.c
>
> If I load "src/foo.c", the "Development" menu is missing the entire "Build Project" submenu, and the two entries in the "Project Options" menu are greyed out. If I load "bar.c" in the same directory as the Config file, the "Development" menu has a lot more options, and most of them available for selecting. Similarly, calling (ede-current-project) returns what I would expect for "bar.c", but returns nil for "src/foo.c". For whatever reason, calling `C-c . C' directly in "src/foo.c" does seem to do the right thing.
>
> So is there something I'm missing that will let EDE recognize descendant files as part of a top-level project? And is there a way to recognize Dired buffers as being part of a top-level project, so EDE commands will work in those as well?
>
> Thanks,
>
> Derek
>
|