[opensource-dev] USESYSTEMLIBS

Henri Beauchamp sldev at free.fr
Tue Dec 15 06:22:33 PST 2015


On Tue, 15 Dec 2015 05:39:43 -0600, Nicky Perian wrote:

> Anyone building using system libs .../... how are you handling the libs
> that have no packages. jsoncpp glh-linear webkit hunspell to name a few.

That's the problem with SYSTEMLIBS (AKA SATNDALONE in v1/2 viewers): you
can't handle those missing depedencies using the default build system,
making it a rather pointless feature of the said build system...

A "long" time ago (8 years), I wrote a make-SL bash script (and later
updated it to "cmake-SL" when the build system migrated from scons to
cmake), that took care for copying selected (and selectable) system
libraries (those actually present on the build system and which version
was compatible with the viewer) and corresponding headers into the
viewer's source tree own lib/ and include/ folders and which updated
the installed "lock" (more like flag) files to fool the viewer's build
system into believing it already had downloaded and untared the
corresponding pre-built packages.
The script also removed the corresponding viewer_manifest.py script
lines that were responsible for copying the pre-built libraries and
packaging them with the viewer. Then the script launched a
non-SYSTEMLIBS/non-STANDALONE build, the build system then only
downloading and untaring the pre-packged libraris that were not already
pre-populated by cmake-SL, causing the resulting viewer binary to be
compiled and linked with the system libraries and packaged without them.

I am still using that script for personal builds, but LL's viewer since
parted from the Snowglobe build system which my viewer is still using
(i.e. I'm not using "autobuild" at all), so it won't be suitable for
your particular use case...

The true and final solution for that problem would be to use
differentiated "<LIBNAME>_SYSTEMLIB" defines in the viewer cmake files,
so to be able to specify the system/pre-packaged choice for *each*
individual library/package.

Henri.


More information about the opensource-dev mailing list