don't include all of libafl for symcc_runtime by default

[julihoh]

Just to avoid adding unnecessary dependencies. It's quite annoying when the build takes very long for dependencies that are not even used...

[domenukk]

What features in default take very long? If you do use default libafl, the way it is now means libafl will be built twice, right?

[julihoh]

To be honest, I saw quite a large dependency tree when I built a project with libafl and jumped to the conclusion that I don't need it all. For example, libafl-derive or llmp-compression and things like that. In fact, I was only using the concolic infrastructure without the actual fuzzing parts of libafl, so I wanted to get rid of any unnecessary dependencies.
I haven't benchmarked anything here and you're probably right, that I would compile libafl twice if I were to include it with default features in a project that also includes symcc_runtime. In my case, I don't need full libafl in any of my crates, but I could see how that's not really the intended use-case 😅
We can also just drop this PR, I'm not really that eager to change it

[domenukk]

Nah it's the use case of libafl to have flexibility and only pick the parts you need. I just don't know what the best way is here. Would be best to have libafl always with exactly the same feature set, but I guess that's not something cargo can do (?)

[julihoh]

Now that you say it... I could actually imagine cargo merging feature flags across the dependency tree. I'll check it tomorrow :)

[julihoh]

When a dependency is used by multiple packages, Cargo will use the union of all features enabled on that dependency when building it. This helps ensure that only a single copy of the dependency is used.

src

I think the default features can therefore be safely deactivated :)

[domenukk]

okay sweet