As for the other option you considered, which is to add an ede-generic project type so long as one can identify some common file that exists at the root of all python projects, this touches on another aspect of EDE that I don't quite understand. When I invoke "M-x ede-new" that ends up creating a "Project.ede" file in the root of my project. Doesn't that file already define the root of a project? Why does one need some other file (e.g., README, Makefile, etc.) to define root? The answer may be in the docs, which I'll re-read again. Thanks!
On 12/18/2013 05:18 PM, David Ventimiglia wrote:Hi David,
It's really messy. The nicest solution would be to have something like
ede-cpp-root-project for python. But at least I could live with some
ad-hoc solution inside semantic, as long as Eric doesn't veto it.
If I had a vote (which I don't), it would be for the "right" solution
(be that EDE) in lieu of something expedient but ad-hoc. I'm in no
hurry. But, I'm afraid I don't (yet) understand the EDE stuff very
well. Is there no generic EDE project type not tied to a particular
language that says, "This file (say, Project.ede) defines the root of a
project. In it, you can specify one or more source directories.
Semantic will look for include files relative to those source
directories, in a way appropriate for the given language."?
As the other David mentioned, I'm not too fond of the generic "project root" variable in semantic. It is one of those things that seemed like a great idea that could do "anything", but then all the things it couldn't do kept showing up, which is why I started focusing on things like EDE which had the API fortitude to handle all the subtle differences in language and source organization.
I also took a run at a generic project which I had called ede-simple. It was eventually removed from CEDET as other simple projects like ede-cpp-root could do a better job with less code by being specific.
The C/C++ support in EDE ended up using a pretty generic API which I hoped could handle multiple languages. The "include" handling in semantic for C/C++ was similarly generic. This did not work very well for Java which needed it's own classpath support in EDE and Semantic to work well which is the other language I know pretty well.
Anyway, the point is that a side effect is that some folks have had success using the cpp-root project with other languages for the purpose of marking the root of a project. If python includes are similarly modeled to c++, (ie - it matches a file on disk you are likely to have access too) you might even be able to use the same C++ slots for system includes etc and point them at python directories. I was going through a python tutorial a while back, so I tried this:
(ede-cpp-root-project "pythontutorial" :file "/home/eric/python/tutorial/test.py"
:include-path '( "" )
It could find 'cookielib', but it didn't find 'sys'. I looked for sys.py but I didn't find the file myself with a system-wide 'locate' call.
Of course, setting the system-include-path via EDE is completely redundant since python sets up the generic one already, but I did see that it added these paths a second time.
Of course, ede-cpp-root may try to do c++ things to your python, and won't do any python specific stuff. That really will need a custom EDE project to avoid, but perhaps this is a good experiment. If it handles the basics, then you could run with that and collect all the missing features and apply that to a new python project type later.
Lastly, it might be possible to add an ede-generic project type if there is some common file that exists at the root of all python projects, the way "Makefile" shows up for some C projects. That allows interactive configuration of the local include paths and is more dynamic.
I hope this helps.