Two different crates trying to link different versions of the clang native library

[futuresdr]

Two different crates trying to link different versions of the clang native library

[bastibl]

I'll close this one but feel free to close yourself when you feel the issue is resolved. Thanks for bringing it up!

[bastibl]

Thanks for opening the issue. I took it as the last nudge to finally fix the crate and sub-crate structure of the project. I did quite a bit of rearrangement. This error should no longer occur. Would be great if you could give it a try.

[bastibl]

And now it's also in the main repo -.- (in case you were trying to pull in the last 10 min)

[jschiefer]

Thank you for the quick turnaround! Yes, the problem that the issue was about, is fixed. I think this is great, because it avoids people from getting confused/distracted when they open the repo for the first time.

However, there is an undesirable side effect. In the previous version, all the examples would (eventually) automatically get little Run|Debug annotations, like so:

This made it really easy to quickly try out a few examples. With the fix for this issue in place, this no longer happens, presumably because the examples are no longer automatically analyzed. Also, when generating a launch.json file automatically, the examples are no longer included. So the net effect is that there is now a lot more hassle involved in running the examples.

[bastibl]

Hmm, I see... that's a downside of the current approach :-/ But I guess one has to die one death here. Some more context: Before the refactor, all examples and performance evaluation projects were sub-crates of the same workspace. Since there are examples for basically every feature available, commands like cargo check --workspace enable all features (i.e., it enables all features that any example/perf sub-crate might enable). This means, if you don't have all (partially obscure dependencies installed), these basic commands would fail. I guess that's the worse case.

With the current project structure, each example is an independent crate that just happens to live in the same directory structure. I don't use the code editor. I assume you'd open the example folder as project, instead of the base directory.

I'm not sure if there are better ways to do it. I'll have a look at some of the popular crates to see how they do it. Apart from that, it should probably be documented that one should open the examples as projects. I put it on my list.

[jschiefer]

Fair enough, having to have all dependencies for all obscure features seems like an uphill battle. So I would agree that the new refactored way is much preferable.
I tried the approach you suggested (opening examples with VS Code, e.g. examples/audio), and this worked fine and seems like a perfectly workable solution. Thank you for taking care of this!

[jschiefer]

This can probably be closed. Would you like me to do this?