search

cps-org / cps

Common Package Specification — A cross-tool mechanism for locating software dependencies
https://cps-org.github.io/cps/
Other
99 stars 8 forks source link

better representation for language standards #9

Open dcbaker opened 3 years ago

dcbaker commented 3 years ago

Currently they're listed as a feature, and can include a limited subset of the language standards (they have c99 and gnu, which is annoying, It would be much nicer to specify "gn99"), but there are some limits to this format (that we've run into in meson). There are some projects (glib in particular) that can be built with gnu99 or c99, but you get more goodies if you use gnu99, so that's preferred, but c99 is acceptable. There currently isn't any way to specify that.

This also ties into the non-c languages, as rust has the concept of "editions", which are basically standards, but with no backwards compatibility guarantees.

mwoehlke commented 1 year ago

It would be much nicer to specify "gnu99")

Specify both C99 and GNU. "GNU" means "I don't care what language level, but I want extensions", while "C99" means "I want (at least) C99 support". This should probably be clarified in the doc; thanks for the nudge!

This also ties into the non-c languages, as rust has the concept of "editions"

Do you think there's a reason the same idea wouldn't work with e.g. rust? Obviously we would need to specify what those features are... (I'm not familiar with rust, so...)

dcbaker commented 1 year ago

I still have the the problem of glib that wants you to use gnu99 if it's available, but fall back to c99 if gnu99 is not available for some reason.

With Rust you can't change the standard for a package, it must be exactly the edition specified.

So a Rust crate built with --edition 2021 cannot be assumed to safely work with --edition 2024, but they make guarantees that crates with different editions can be linked together