CMakeLists.txt incorrectly assumes that any LSB release ID that's not 18.04 must be 16.04

[danielhatton]

Issue overview

In the CMakeLists.txt file in the root directory of the OpenStudioApplication source tree, lines 399-406 are an if...else construct, which tests whether the host system's LSB release ID is 18.04, and if not, assumes the LSB release ID must be 16.04. I think it's using LSB release ID as a proxy for Ubuntu version number. The current LTS release of Ubuntu has LSB release ID 20.04, so the assumption is no longer widely valid.

Current Behavior

On an Ubuntu 20.04 machine, the "ccmake" step of the OpenStudioApplication build process assumes the LSB release ID is 16.04, and downloads a tarball of pre-compiled Qt libraries suitable for Ubuntu 16.04. Once the tarball is downloaded, the build process fails with an error message about a hash mismatch for file qt_5_11_linux_shared_xenial.tar.gz. (I'm guessing the hash mismatch will happen even if the host system really is Ubuntu 16.04.)

Expected Behavior

Straightforward answer: the script should successfully detect when the LSB release ID is 20.04, and download a tarball suitable for Ubuntu 20.04 (or, if that's not possible, should exit with an error message "Sorry, building on Ubuntu 20.04 is not yet supported.").

Deeper answer: I'm a bit uncomfortable with the idea that the build-from-source process, for an application marketed as open-source, involves downloading (and presumably compiling against) off-distro pre-compiled libraries. Perhaps the real expected behaviour should be that the application compiles against the host system's native Qt libraries, or downloads (then compiles) a Qt source tarball rather than a pre-compiled Qt tarball.

Steps to Reproduce

On an Ubuntu 20.04 system, follow the build instructions at the end of https://github.com/NREL/OpenStudioApplication/blob/develop/README.md

Possible Solution

One way might be to add to the amazonaws repository a pre-compiled Qt library tarball suitable for Ubuntu 20.04. Then, between lines 401 and 402 of CMakeLists.txt, add

elseif(LSB_RELEASE_ID_SHORT MATCHES "20.04")
set(QT_ZIP_FILENAME "a_library_appropriate_for_20.04.tar.gz")
set(QT_ZIP_EXPECTED_MD5 "the_appropriate_hash")

or, if no appropriate tarball can be created

elseif(LSB_RELEASE_ID_SHORT MATCHES "20.04")
message(FATAL_ERROR "Sorry, building on Ubuntu 20.04 is not yet supported")

Details

I tried editing CMakeLists.txt so that (on the Ubuntu 20.04 system) the script would download the pre-compiled Qt library tarball considered suitable for 18.04. In this case, ccmake completes successfully, but then the "make" step fails with an error message about not being able to find libicui18n.so.60

Environment

Platform: Ubuntu 20.04
OpenStudioApplication version: 1.0.0

Context

Am trying to build and install OpenStudioApplication on Ubuntu 20.04.

[jmarrec]

@danielhatton This is (strongly) related to the conversation on #11. FWIW, the official target platform for Ubuntu is now 18.04, whether it be for NREL/OpenStudio (the SDK) or NREL/OpenStudioApplication. That being said, with increasing adoption of 20.04 LTS I think this should be enabled. I would re-title the issue as "Allow building OpenStudioApplication on Ubuntu 20.04" I think.

[danielhatton]

Thanks, @jmarrec. You're right that #11 is relevant. The fundamental issue is that OpenStudioApplication needs Qt to be built with very specific compile-time options, right? Are we quite sure that the enormous plethora of Qt packages in the Ubuntu repositories (or indeed in the repositories of other distros) doesn't include anything with the right compile-time options?

(I think there are analogous things going on with a bunch of other dependencies, too. For example, it looks like the OpenStudio build process is downloading its own copy of Radiance, even though I already have Radiance installed on this machine.)

[jmarrec]

Yes, that's the fundamental issue. The webengine/chromium stuff for one is a major thing we need which needs to be specifically enabled when compiling Qt. And it does requires quite a few system libs and things in your PATH for the compilation to succeed (otherwise it fails compiling it silently, when for eg you do not have python2.X (yes 2.X, not 3.X) in your PATH which is something I found when I toyed with using conan to provide Qt).
The compilation on the fly is also something you want to avoid since it'll basically take somewhere between 20 and 40GB on your disk and takes a ridiculously long time.

Mind that we are cross platform: ubuntu, mac, and windows. So relying on system deps/packages instead is a ton more complicated.

There are a few things we do download via cmake such a radiance and EnergyPlus. Yes, you might have your own installation, and that installation could be the right version and stuff. But relying on developpers to install their own dependencies, constantly keeping it up to date, only to save 50Mb in the end doesn't appear like a good tradeoff. Another drawback is that suddenly we have to make a bunch of code more complicated because it's no longer as easy to find stuff (on all platforms, you will have a ./build-folder/EnergyPlus-9.3.0-SHA-<platform>/ directory since we download and extract it...)

[danielhatton]

Thanks, @jmarrec. I guess you really know this already, but the 50MB occupied by the libraries is not the main problem with the current approach. The three main problems are:

• a security problem: downloading binaries from unfamiliar websites is, AIUI, generally considered high-risk for malware infection (I think amazonaws counts as "unfamiliar", even though I'm aware that the site has some sort of relationship with GitHub);
• an ethical problem: the README.md file fails to mention that the ccmake step will download (and then the make step will compile against) precompiled binaries, which denies end users the opportunity to make an informed decision about whether to take the aforementioned security risk; and
• a possible legal problem: in GPL language, the NREL team is "conveying the object code" of the LGPL-licensed program Qt, in which case the NREL team is required to meet one of conditions a-e in section 6 of the GPL. As far as I can see, none of the additional permissions in the LGPL make any difference to this. Yet I can't see any way in which any of conditions a-e are being met - or am I missing something blindingly obvious? (IANAL)

[lgentile]

The OpenStudio Application is distributed under a BSD3-style license, https://github.com/NREL/OpenStudioApplication/blob/develop/LICENSE.md

The Application makes use of a subset of dynamically linked Qt library modules, licensed under GPL 3.0 and LGPL 3.0. Let us know of any specific questions regarding compliance requirements a-e.

[danielhatton]

Thanks, @lgentile. The possible legal problem doesn't arise in the process of using dynamically linked Qt library modules - that process is (under certain runtime conditions which I hope are being met) exempted, by section 4 of the LGPL, from requirements a-e of section 6 of the GPL.

The problem arises instead in the process, initiated by the CMakeLists.txt build script of OpenStudioApplication, whereby a binary-form copy of Qt is downloaded from an NREL-controlled amazonaws repository. By my reading, that NREL-provided copy of Qt is not a "system library" by the definition in section 1 of the GPL, but is instead a "work" which NREL is "conveying in object code form", and it's that act of conveying that attracts the obligations in section 6 of the GPL. But as I mentioned, I am not a lawyer, and if you want to be really sure about this, you should probably consult someone more qualified than me.

The way forward I'd suggest (see above) is for OpenStudioApplication to compile against a distro-provided Qt, instead of the CMakeLists.txt script downloading its own copy of Qt. In that case, it would be the distro maintainers, not NREL, doing the conveying; and it would be the distro maintainers' problem, not NREL's, to work out how to comply with section 6 of the GPL. Distro maintainers are very good at that, and I think I would go as far as to characterize it as the "normal" way for an open-source project to use a dynamically-linked library. However, @jmarrec has expressed concern about some additional complexities associated with that approach, so it might not fly.