Fix install directive to also install sai2.hpp and util.hpp, install into libsai subfolder

[luspi]

The current install directive in CMakeLists.txt omits the sai2.hpp and util.hpp header files.

Also, I added another change in this pull request, where the three header files are put into a libsai subfolder (e.g., /usr/include/libsai). This is mostly due to the util.hpp header file, as it has a rather generic name and is currently placed in the same folder as many other headers, making a conflict between two util.hpp files nonzero (albeit still small). What do you think about this change?

[Wunkolo]

Thanks for the PR!

Also, I added another change in this pull request, where the three header files are put into a libsai subfolder (e.g., /usr/include/libsai).

I think I might prefer sai rather than libsai. At some point I can see myself refactoring this library in the same way so that the user-code of this library can look something like:

#include <sai/sai.hpp>
#include <sai/sai2.hpp>
#include <sai/util.hpp>

or maybe even something like this in the future:

#include <sai/archive.hpp>
#include <sai2/archive.hpp>

I think this also matches a somewhat common pattern a bit where library-code libfoo and libbar would have include-paths like foo/... and bar/...(omitting the lib* part). Such as what libsdl and libboost and libcurl and such do.

[luspi]

That makes sense. I changed it for now to be sai instead of libsai.

Unrelated to this PR, but since you mentioned sai2, is there any sort of documentation already about that header API? No worries if not, just wondering if I missed something :)

[Wunkolo]

Thanks!

Unrelated to this PR, but since you mentioned sai2, is there any sort of documentation already about that header API? No worries if not, just wondering if I missed something :)

I haven't documented it, no. Just raw code at the moment serving it's immediate purpose over in SaiThumbs! The high-level document structure is so much simpler than the first Sai that the complexity is only really introduced when it comes to storing the actual layer-data itself. I've largely moved onto Clip Studio as my main art program so libsai is fairly de-prioritized as a project but I do try to clean things up and refactor things where I can as the developer-demand increases. Reverse engineering sai 1 was a lot of work for what ultimately became little usage other than SaiThumbs, so I'm trying to keep my input somewhat proportional to the value these days.

[luspi]

That makes sense. Unfortunately I don't know much about SAI myself to help more, I only know enough to implement a simple parser using libsai for SAI images (and others) in an app I'm developing. Everything I know about SAI for doing that I learned from you, so thank you for that!