David Ventimiglia writes:`semanticdb-project-roots' doesn't work as advertised in the
> I have a Python project rooted in this directory
> So I added that directory to semanticdb-project-roots.
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:
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 guess that should be import?
> I then have a Python
> module in
> Which has lines like these
> include authsvc.providersimpl.db
> include authsvc.providersimpl.test
If you apply your patch from the mail above, then those imports should
> And then I have those corresponding Python modules in
> 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.
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
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.