On Wed, Dec 18, 2013 at 1:56 PM, David Engster <deng@randomsample.de> wrote:
David Ventimiglia writes:
> I have a Python project rooted in this directory
>     $HOME/devel/authsvc
> So I added that directory to semanticdb-project-roots.

`semanticdb-project-roots' doesn't work as advertised in the
doc-string. When I researched the history of this variable a bit, I saw
that you already dealt with this in 2011 and even provided a patch:


That's true.  I did.  I didn't know if that patch had been incorporated or if some other solution had been found.  I stopped trying to use CEDET for Java about 3 years ago but kept tabs with CEDET and perceived that its Java support had improved.  Recently, I again tried to use CEDET, this time with Python projects.

I know that Eric is not too fond of having those semantic* variables
still around which do project-specific stuff; this would indeed better
fit into EDE. However, we do not have a proper EDE project for python,
so I think those variables like semanticdb-project-roots should really
work as advertised (or removed altogether).

I'm not opposed to using EDE.  It's just that back then, and now, the semanticdb project roots seemed conceptually simpler and easier to use. 

>   I then have a Python
> module in
>     $HOME/devel/authsvc/authsvc/authidentityproviders.py
> Which has lines like these
>     include authsvc.providersimpl.db
>     include authsvc.providersimpl.test

I guess that should be import?

Yes, it was just a typo.

> And then I have those corresponding Python modules in
>     $HOME/devel/authsvc/authsvc/providersimpl/db.py
>     $HOME/devel/authsvc/authsvc/providersimpl/test.py
> Yet, those include statements are have the red face color, and are regarded as
> "Uknown."  If I find-file on say db.py so that the file becomes parsed and its
> tags loaded into the cache, then sure, the include statements turn green and
> it's listed as "Fileless" but I can't jump to the file (naturally, since it's
> Fileless) and I can't complete any tags from it. 

If you apply your patch from the mail above, then those imports should
not become red. However, they will still be shown as "fileless".

The reason for this is that there are two things at play here: finding
the database table for the include, and finding the actual file. Those
two things are separated, since there are programming languages where
"importing" or "including" things does not necessarily mean that those
are tied to actual files.

So your patch above will fix semanticdb-find-table-for-include, which as
the name says finds the database table. The *file* however is searched
by semantic-dependency-tag-file, and that still returns nil. This is
what "fileless include" means.

Having said that, I'm not really sure how to fix this. Using the
semanticdb-project-roots variable in `semantic-dependency-tag-file'
feels wrong, since it doesn't belong there. I guess this should actually
be better fixed by using semantic-dependency-include-path, which however
is buffer-local.

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."?