Our project is a cross-platrorm, open-source implementation of some programming language. In addition to a command-line executable to execute programs in that language, it also provides a C++ API and library that the user can use to add their own modules.
I’m trying to decide whether it’s worth it (or even if it even makes sense) to provide our stuff as a framework (via a .pkg file) for Mac OS X. If we do nothing, then there is still the make install target that would put everything into /usr/local/include, /usr/local/lib, etc.
Our implementation requires some 3rd-party libraries, e.g., Xerces and ICU. Can/should pre-built versions of these libraries be considered “resources” and bundled in a framework? Is this a legitimate way to distribute 3rd-party libraries?
I like frameworks, they keep things tidy. A framework would make it easier to use your library with Xcode, but it would also be convenient for command-line usage (-framework MyCoolLang). People can then #include and use your headers without setting up separate search paths.
This means that you should be putting your headers in
/usr/local/include/MyCoolLang/{foo,bar}.hon other platforms as well, so that people can use the same relative include paths. You should be doing this anyway since it’s tidier.If you must support include paths with no subdirectories, eg #include , and/or if you want to support traditional compiler options like -lMyCoolLang when compiling from the command line (as an alternative to -framework), you can symlink the headers and/or the libraries into /usr/local/lib and include. This is still better than dumping the actual files in there because someone can just ls -l /usr/include and tell exactly which headers belong to your framework by the symlink path.