On 10/25/2010 06:07 AM, Ralf Mattes wrote:
> On Sun, 24 Oct 2010 21:58:18 -0400, Eric M. Ludlam wrote:
>
>> On 10/20/2010 05:38 PM, Ralf Mattes wrote:
>>> Hello list,
>>>
>>> I have a project that uses automake/autoconf but wold like to provide
>>> my own Project.el file (I need to tweak includes etc.). Somehow ede
>>> just ignores this Project file - at least when I run
>>> ede-object-root-project from a file in this project I get a
>>> 'project-am-makefile'. What am I doing wrong?
>>
>> Hi,
>
>
>> Project.el has to have the definition of an ede-proj-project in it.
>
> Ah, that seems to be the bit of information I was missing. So I has to
> be of type ede-proj-project and can't be an ede-cpp-root-project.
> Hmm, is there any technical reason for this (besides it being hardcoded
> in ede-proj.el ...).
> I'd love to be able to define project wide setting in a Project.ede file
> (btw, I assume you meant 'Project.ede' and not 'Project.el' in your reply)
> that I can keep under version control (and that I can actually aout-
> generate from a configure script ... that's really important to get the
> includes right).
EDE is supposed to identify a project dynamically, and the Project.ede
file is a variant where EDE can create the Make system harnesses for
you. Otherwise EDE is supposed to look in a directory, and derive the
correct settings instead. What you describe is out of that model, but
is also a fine thing to request.
In this case, what you probably want is the generic project type which
has a save file only for the minor configuration bits in the file
EDEConfig.el. That will include the include paths. The Generic type
doesn't support Automake by default due to the specialized Automake
project type.
Thus, to do what you want involves removing the project-am.el autoload
cookies, and adding in Automake support into ede-generic.el. (Near the
end where there are three examples.)
It might be possible to rig the specialized Automake to include support
for an EDEConfig.el also. I'm not sure what that would take.
>> If
>> not, then EDE will ignore the file. Check for error messages to see
>> what it is doing.
>
> How should I put it: "Corrupt project file" for a file that evals to an
> ede-cpp-root-project is kind of misleading, or? :-)
Well, that's what it is. I'm open to any patch on the topic however. :)
>> Since EDE caches loaded projects, you will probably
>> need to restart Emacs to see what the error is.
>
> Where actually does ede cache these things? Any reasonable cache should
> have a way to flush/reset it. Restarting my OS is so Win95.
Of course, that is what I do while testing. It's just easier to suggest
a restart when I have no idea what the technical skills of the person
I'm emailing is. It's also less typing.
Step one, clear the variable ede-inode-directory-hash. The contents are
purely for optimization.
Step two, look at the contents of ede-projects, find the one you want to
remove, and delete it. For example, move to a file where the buffer
local variable ede-object-root-project is the project to trash, and then:
M-: (setq ede-projects (remq ede-object-root-project 'ede-projects)) RET
Then kill all the buffers that are part of that project.
I suppose that would make for a handy function. I've never bothered
creating such a thing.
>> ede-object-root-project is a variable, not a project type. The
>> project.el file only needs an instantiation, not any assignment code.
>
> I 'M-x eval-expression'ed it to see what ede considered to be my project
> settings.
>
>> You can use the Project menu to create a new project, then use
>>
>> M-x customize-project RET
>>
>> to edit things like the custom include paths. If you don't need it to
>> create Makefiles and such, you can just use the ede-cpp-root project
>> style which is installed in your .emacs file.
>
> Ah - nice, but not a place I'd expect project settings in. Shouldn't such
> information go into the customisation file?
Yea, that is a quick hack to cover any kind of weird build system, and
to accommodate folks who did not what project files cluttering up their
directories.
>> You can also use the project-am-makefile type (which is for Automake) by
>> setting project-am-localvars-include-path as a variable. I didn't
>> realize this feature existed, but it looks like you can just set this
>> variable to a list in your .emacs file like this:
>>
>> (setq project-am-localvars-include-path '("path1" "path2"))
>
> As I said, I need these things to be settable from within the project
> directory.
>
The last step to solve this problem is to create your own project style
that will automatically setup any defaults you need. The ede-emacs and
ede-linux types are fine examples of something like that, even though
both are based on project systems that are already supported by EDE in
some other way. For the same reasons as well.
If you enjoy a good hack, then this is the way to go.
Alternately, feel free to patch project-am.el to include loading some
alternate configuration, and we'll see if we can put it in with the
right paperwork for copyright assignments.
Eric
|