Open AmateurECE opened 3 months ago
Thanks for your interest in this project!
in general, C-style preprocessor directives (such as #include
or #define
) are not supported at the moment. This is because initially, I only want to get the pure device-tree language correct and design a language server for that. But supporting such directives are definitely one of the next challenges I want to tackle. Given that this is just a hoby project and I have some other open-source stuff I want to attend, I cannot make any guarantees concerning timing though.
Concerning the related configuration question; currently I see two options:
1) Through the command line (i.e., ginko <files>
): Just use options, i.e., ginko foo.dts -I/usr/lib/...
.
2) When used within a language server. In this case, I would use the builtin options the language server protocol enables to pass configuration options.
But some configuration file might also be worth exploring, maybe also looking into the future to have more control over emitted diagnostics or lints.
I very much appreciate any help, but enabling C-style includes is certainly a pretty big change.
In the same vein as #10,
#include
directives with angle brackets appear to cause syntax errors, but these appear all over the kernel to refer to symbols commonly used in device tree bindings. This file:Produces this diagnostic:
If the included file exists at
$PWD/dt-bindings/input/linux-event-codes.h
, I can compile this device tree file usinggcc -E -P -x assembler-with-cpp -I$PWD -o test.dtsi test.dts && dtc -o test.dtb test.dtsi
.This perhaps brings up a related question--how should users configure
ginko_ls
? Presumably, I as a user want to be able to informginko_ls
about the "system include" paths on a per-project basis. Forclangd
, this can be done with a.clangd
file.