I’ve created a PKGBUILD script so that I can more easily install the latest release of the SOUL headers and shared library on my Arch Linux machine, which got me thinking about where the idiomatic Linux-feeling place to put these things would be.
For the shared library it is obvious to put it at
/usr/lib/libSOUL_PatchLoader.so, but the header files are less obvious…
My first thought was to pull the header files out of their API folders and put them all together in
/usr/lib/SOUL so that I could include things like
#include <soul/soul_patch.h>. It would be even nicer if the files were named more tersely so that I could write
#include <soul/patch.h>. Unfortunately, it looks like because of the way the header files refer to each other, a lot of the directory structure in the repository has to be maintained in order for e.g. headers with helper classes to find the main headers they use, or for main header files in the API to find the 3rd party dependencies from choc.
I settled on moving the whole
3rdParty directories into
/usr/lib/soul/, so to include
soul_patch.h I write
#include <soul/API/soul_patch/API/soul_patch.h. That’s a bit of a mouthful, but it works I guess.
Looking at the example code and some of the other projects I’ve seen, it seems expected that the headers should just be sitting somewhere nearby your project so that you can include them using a path relative to the source code. This seems damaging to the ecosystem; if I want to work on someone else’s cool open source SOUL project, I have to either patch every location that includes a SOUL header to look for them in the place where I happened to install them on my system, or switch my installation method to conform to the other project, or maybe set up some symbolic links so that the other project can still find things via links to their location on my setup…
Maybe it would be a good idea for there to be an agreed upon, canonical, expected location for at least the header files, so that everyone can just write the same
#include statements and expect it to work.
And if such a convention were to be instituted, maybe it would also be a good time to rework the directories a bit so that we can all write more concise
#include statements (
<soul/API/soul_patch/API/soul_patch.h>) while we’re at it. This could even be done without changing the existing directory structure by adding dummy headers in
/source (or wherever the
includeable API ends up living permanently) that just
#include the relevant files.
I imagine it might look something like this (at least on *nix systems):
/usr/lib/soul/patch // dummy file includes API/soul_patch/API/soul_patch.h /usr/lib/soul/venue // dummy file includes API/soul_venue/API/soul_venue.h /usr/lib/soul/future_api // dummy file includes API/soul_future_api/API/soul_future_api.h /usr/lib/soul/API/... // existing API folder /usr/lib/soul/3rdParty/... // existing 3rdParty folder
Then we could have concise include statements while still allowing header files in the API to reference each other relative to their position in whatever arbitrary directory structure they live in.
What have other people been doing when installing SOUL for development? Is anyone else… dissatisfied… with the current include statements? Also, how would this look in a Windows environment ideally?
I guess you guys on the development team are swamped with other much more important things, but have you given this any thought? Is the way we include soul APIs likely to change in the future, or is the current status the expected method for all time?