Binary Release

[AaronBallman]

We've been discussing whether to do a binary release or not, but one thing we may want to change if we want a binary release is our use of angle bracket includes.

Popular compilers (Clang, GCC, and MSVC) all perform different lookup heuristics when encountering angle brackets vs quotes for file inclusion. Namely, they'll include the directory containing the source file doing the inclusion on the search path only when using the quoted include paths.

If we're thinking of doing binary distributions of a shared library, one common build configuration is for users to download the header files and shared libraries (bypassing our CMake entirely), so they may put the header files next to their source file and not change the include paths passed to the compiler. However, this will fail because we use angle brackets for including things that are local to our source. Their #include "gtirb/Module.hpp" may find the correct file, but our #include <gtirb/Addr.h> may fail due to header search paths.

The approach I'm used to is to prefer quoted includes for any header files supplied as part of the root include/ directory and angle bracket includes for things the user is expected to make available themselves (STL, system headers, etc). However, our header files are laid out... more complicated than that. We have include/gtirb that we supply, but we also have boost/include/boost that we supply, and then there's gsl and googletest which we don't supply as part of the source directory but the user cannot supply either with their own version (due to ABI issues), but we rely on as part of our header files (at least for gsl, we do).

[dornja]

This issue would seem to imply that, despite having an "install" target in the CMake file, we don't really support installing GTIRB yet. The compiler is going to need to find the GSL and Boost headers in order to process the GTIRB headers. Since we don't install them, the user would have to provide (the correct versions of) them or rely on the versions in the build directory.

Is there a best practice for installing headers that depend on GSL? I don't see one in the CppCoreGuidelines document, but I didn't look very far. I wasn't able to find an Ubuntu package for it either...

[AaronBallman]

This issue would seem to imply that, despite having an "install" target in the CMake file, we don't really support installing GTIRB yet.

Yes, I think this is accurate. In terms of actual release mechanisms, there are two different kinds of releases we need to be concerned by.

1) development releases where someone wants to develop against the GTIRB release. This release would need to have shared libraries, headers, documentation, examples, etc. 2) binary releases where someone wants to release their project which includes GTIRB. This release would not need headers, documentation, etc.

For (2), I think we basically want to be able to trust that sudo apt-get install gtirb (or the likes) would be sufficient on Linux platforms. On Windows, we should have an installer that can be run as part of a larger installer for a product. For (1), I think we want sudo apt-get install gtirb-devel (or the likes) to work on Linux platforms. On Windows, it's a bit unclear to me what the best approach is (perhaps vcpkg integration?). I think both (1) and (2) needs to support picking the install location (e.g., next to an executable vs system-wide).

I think the cmake install command probably gets us somewhat close to solving (1) but also probably still needs more effort for things like versioning (developing against two different gtrib versions at once, such as a gtirb upgrade tool might wish to do).

[eschulte]

We now have Linux packages allowing users to easily install GTIRB, see https://grammatech.github.io/gtirb/#installing. E.g., on Ubuntu apt-get install gtirb will work once you add our package archive as described in the above link. I think this is sufficient to close this issue.

If anyone would like to see a particular new format of binary release please open a new issue.