AIS NMEA messages about nmea

[Dushistov]

Here's a WIP list of features we can use to separate the different message parsing of the crate and allow people to only use a certain message(

Every new feature is not small thing, it is increase testing efforts (we need check 2^number_of_feature combinations),
it need documentation and so on. Is any reason to add such features?
Linker even without LTO can remove unused code, and removing dead code is default option for no_std builds.

[elpiel]

It's still a matter of pulling the code and compiling it, even when optimizing. It would be nice to test all features separately, however, I don't necessarily think that we should.

I'm also adding this issue as part of #47

[Dushistov]

It's still a matter of pulling the code and compiling it, even when optimizing.

Not sure that follow you here. You mean that compilation of code for parsing one message is so slow,
that it is worth extra feature to disable it? On my machine in release mode compilation of nmea crate takes < 1 second,
why care about fraction of second?

It would be nice to test all features separately, however, I don't necessarily think that we should.

So if code don't compiled for user, because of feature X reference code hidden under feature Y,
it is not our problem? I suppose we should test all features combination with help of CI.

[elpiel]

Not sure that follow you here. You mean that compilation of code for parsing one message is so slow,

@Dushistov Let me rephrase that - you can't optimize the parsing part because messages are dynamic. No matter what you pass inside, str, bytes, you will have the parsing of the different message types, i.e. it will not be optimized (see Nmea::parse()).
You're still going to have the code for parsing all message types inside the binary and if you have an embedded system with limited memory this can make a difference.

As an example, the uuid crate can parse UUIDs but can't generate them if you don't allow a given feature (https://docs.rs/uuid/latest/uuid/#dependencies).