Required dependency on Dashel

[davidjsherman]

Dashel is currently a required dependency for Aseba: https://github.com/aseba-community/aseba/blob/29b39bc39dde88f6d8f6489e7cf114d164c73e69/CMakeLists.txt#L66

However, not all Aseba products require Dashel. In particular libasebacompiler.a, libasebavm.a, libasebavmbuffer.a, and libasebavmdummycallbacks.a don't refer to Dashel.

:warning: Requiring Dashel adds an unnecessary constraint when building Asm.js and Webassembly versions of the Aseba compiler.

Of couse most Aseba products do require Dashel. Wrapping each one in a conditional DASHEL_FOUND would be fastidious and would needlessly change the indenting in every CMakeLists.txt. To avoid this, it may be simpler to only include the product subdirectories when Dashel is found. https://github.com/aseba-community/aseba/blob/29b39bc39dde88f6d8f6489e7cf114d164c73e69/CMakeLists.txt#L142-L148

[stephanemagnenat]

Agreed, we should change that as part of the CMakeLists refactoring. Could you please add this to your list @cor3ntin?

[cor3ntin]

I'd like to move some stuffs around again

aseba/common/ does not depend on anything but aseba/common/** does ( aboutqt, zeroconf ) I'll probably move aseba/common/about to aseba/about and aseba/common/zeroconf to aseba/zeroconf

That would let us build aseba/common/, aseba/vm and aseba/compiler without dashel cleanly

[stephanemagnenat]

commen/msg depends on Dashel.

[cor3ntin]

@stephanemagnenat indeed. I will therefore let things are they are and fix them once the initial cmake rework is merged, as it would be too involving otherwise. ( basically, I need to split msg in its own lib, or something like that )

[stephanemagnenat]

Originally indeed common/ was designed to have everything that was not a client, a switch, a transport layer or a target. Over time more things were added. We could probably split it the following way:

• common/ everything that just depends on C
• utils/ generic helper stuff that just depends on C++
• msg/ message library, depends on C++ and Dashel
• about/ about library, maybe to be split into qtutils/ and utils/ for the part that depends on Qt and the one that does not.
• zeroconf/ zeroconf library.

[cor3ntin]

@stephanemagnenat agreed. I will do that after the cmake refactor is merged. However, moving headers relative to the root directory is a source-breaking change so there will be work to be done in VPL2, and probably others projects.

[stephanemagnenat]

Yes, I agree, it is not a very short term issue.