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
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.
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: