Structure restructuring repo

[Simon-Stone]

No description provided.

[paul-krug]

Looks good generally, but I do not like the way include/ is split up into Backend and VocalTractLabApi, since the source files are not split up either.
In any way, a more fitting name for the api files would be API_C, as we may add a c++ api in the future. For the backend, I'd prefer lowercases, backend.

[paul-krug]

Is the a specific reason that makes this change possible?

[Simon-Stone]

Looks good generally, but I do not like the way include/ is split up into Backend and VocalTractLabApi, since the source files are not split up either. In any way, a more fitting name for the api files would be API_C, as we may add a c++ api in the future. For the backend, I'd prefer lowercases, backend.

Splitting up the header files into Backend and VocalTractLabApi folders is best practice to avoid ambiguities. Let's say we were to use some other library at some point that included a header file with a name that already exists in the backend or API. If the header files were at the root level of include/, there was no way to unambiguously choose the right one to include. Using the subfolders, you just set the include/ directory and then include like so:

#include "Backend/Glottis.h"
#include "SomeOtherLib/Glottis.h

(This of course brings to attention the fact that we don't have namespaces in our codespace, but that is a topic for another time)

[Simon-Stone]

The uppercase Backend is conforming to Peter's conventions. As is the name VocalTractLabApi.

[Simon-Stone]

And yes, there was a reason why CMake 3.13 is required now, but I'm gonna have to check which routine made that necessary.

[paul-krug]

Splitting up the header files into Backend and VocalTractLabApi folders is best practice to avoid ambiguities. Let's say we were to use some other library at some point that included a header file with a name that already exists in the backend or API. If the header files were at the root level of include/, there was no way to unambiguously choose the right one to include. Using the subfolders, you just set the include/ directory and then include like so:

I get that, but why are the source files not split up, its the same situation isn't it?

[Simon-Stone]

That would still be VocalTractLabBackend.dll or *.so, then.

[Simon-Stone]

Hm, maybe we should change the name of the Backend folder(s) to VocalTractLabBackend? Seems more consistent compared to the API folders. And just Backend seems very generic.

[paul-krug]

Hm, maybe we should change the name of the Backend folder(s) to VocalTractLabBackend? Seems more consistent compared to the API folders. And just Backend seems very generic.

Yes, VocalTractLabBackend sounds better.

[paul-krug]

That would still be VocalTractLabBackend.dll or *.so, then.

True, you are right.

[Simon-Stone]

Okay, I thought that we could simply wrap the VocalTractLabApi header around the static VocalTractLabBackend lib and build a shared lib from it, but apparently it is not as straight-forward. The recommended way of doing it is to include all the backend sources again explicitly when building the shared API library.

[paul-krug]

JD2 should be removed from resources, it is not possible to load this file anymore.