idlib is currently limited to C/C++ because that was the original need, and also because most mainstream languages (e.g. Go, Rust, NodeJS, ...) have package management systems with machine-readable SBOMs. Nevertheless, surely code duplication happens in those languages too, and there's no reason why idlib couldn't support them.
Challenges are tangential:
indexing time is already more than half of what GitHub runners allow (2.5 out of 4h). We will have to find a better way and/or optimize the existing code.
the database will have to be extended with a column indicating the language
library-level vs. file-level to support mixed languages? The latter might complicate everything. I'd like to keep it as simple as it is.
idlib is currently limited to C/C++ because that was the original need, and also because most mainstream languages (e.g. Go, Rust, NodeJS, ...) have package management systems with machine-readable SBOMs. Nevertheless, surely code duplication happens in those languages too, and there's no reason why idlib couldn't support them.
Challenges are tangential: