You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But I have a few projects in the closure that include both C and Ada files, via the Languages attribute in the .gpr file. When I parse those projects via lal.UnitProvider.for_project, I get warnings on stdout (or stderr, not sure):
cjson.gpr:8:25: language unknown for "cJSON.c"
Obviously, libadalang cannot do anything with the C files, but it would be nice to just ignore them.
If I remember right, GNATCOLL.Projects supports this, but you need some initialization to register the language extensions. So maybe for_project needs a parameter like a dictionary mapping language names to extensions.
The text was updated successfully, but these errors were encountered:
Thanks for the heads up. I think we just ignore the C files, but somehow GNATCOLL.Projects is still generating those warnings. We'll take a look into why it does that.
Thanks for the heads up. I think we just ignore the C files, but somehow GNATCOLL.Projects is still generating those warnings. We'll take a look into why it does that.
I think it doesn’t ignore “C” files.
I think the project might have an explicit list of file names, including “json.c” for instance. GNATCOLL (and libgpr)
are just telling us that this file, which it knows is part of the project, has no known language.
In GNATCOLL, this is done by registering extensions (“.c” and “.h”) for all languages we want (perhaps there even
is a function to register some usual extensions).
Since you have no way to know the full list of languages the user wants to support, I think you might have to
expose a function to let users do that. As I remember, as of 3 years ago, GNATCOLL came with a python API
for the projects (extracted from GPS). If it still exists, perhaps we should simply get access to it. Then such
issues are gnatcoll issues, not libadalang issues, and you are out of the loop :-)
Manu
P.S. When you experiment on windows, be aware that using GNAT native 12.1.2 exposes a bug in libadalang's Create_Context function that is used within the functions I just referred you to!
I am not trying to parse C files :-)
But I have a few projects in the closure that include both C and Ada files, via the
Languages
attribute in the.gpr
file. When I parse those projects vialal.UnitProvider.for_project
, I get warnings on stdout (or stderr, not sure):Obviously, libadalang cannot do anything with the C files, but it would be nice to just ignore them.
If I remember right, GNATCOLL.Projects supports this, but you need some initialization to register the language extensions. So maybe
for_project
needs a parameter like a dictionary mapping language names to extensions.The text was updated successfully, but these errors were encountered: