Create symlinks that don't include the version

[alistair23]

To make libtock-c builds easier to manage let's create symlinks to the libraries that don't include the version information

[lschuermann]

I don't quite follow how this makes things easier to manage. Also, ln -s will probably fall over when the symlinks already exist.

[alistair23]

Hard coding the version in the file path makes using libtock-c from other repos difficult as it's hard to tell where the libraries are installed

[bradjc]

I don't understand why we would want this.

[lschuermann]

Hard coding the version in the file path makes using libtock-c from other repos difficult as it's hard to tell where the libraries are installed

This seems to cover a somewhat niche use-case, right? Where you're not using libtock-c including its build infrastructure out-of-tree, but either using your own build infrastructure, or needing to reference its particular libc / libc++ yourself.

In that case, I'm not sure whether a symlink is the right approach. Isn't there some way to have a file that you include, which simply exports the version and path of those libraries? That avoids modifying the libtock-c tree itself dependent on a build. Something like a symlink would not be stable in environments where we're building with two compiler versions or where we're able to select the libc version per build.

[alistair23]

This seems to cover a somewhat niche use-case, right? Where you're not using libtock-c including its build infrastructure out-of-tree, but either using your own build infrastructure, or needing to reference its particular libc / libc++ yourself.

It's the use case where you use libtock-c as a library. I'm not sure it's really niche as lib is in the name :)

The problem with having dynamic paths is that it's difficult to use libtock-c from other projects, as the location of the libraries and headers changes

In that case, I'm not sure whether a symlink is the right approach. Isn't there some way to have a file that you include, which simply exports the version and path of those libraries? That avoids modifying the libtock-c tree itself dependent on a build. Something like a symlink would not be stable in environments where we're building with two compiler versions or where we're able to select the libc version per build.

Yeah, the symlink doesn't work if you want to change libc versions or doing strange compiler things, but that seems like a niche use case.

[ppannuto]

There are NEWLIB_VERSION_{cortex-m0,rv_32,...} variables defined by the build system that anything that needs that information can just use directly (they come from Configuration.mk, which is pulled in by AppMakefile.mk). I think using the "actual for this build" variable would be more robust for any downstream use.

---

Another thing in my head now w.r.t. to symlinks specifically a as a solution: One of the takeaways from TW7 is that there is a growing, serious user base of Windows-native folks for Tock and its ecosystem. We've had Windows as best-effort support for a while, but if there is growing external demand+support, we will probably need to escalate it to a first class citizen. This is relevant here as IIUC symlinks+windows is a no-go for anything robust :/.