Qt UIC thing preventing build from source on Fedora

[shaomeng]

When I try to compile the latest VAPOR code on a Fedora machine, I run into the following error, seemingly rooted from QT UIC thing.

Note, I've tried both bundles of 3rd party dependencies:

1. 2023-Sept-Ubuntu22.tar.xz
2. 2023-Sept-suse.tar.xz

and they both fail with this Qt UIC thing.

Error message:

[ 57%] Automatic MOC and UIC for target vapor

AutoUic subprocess error
------------------------
The uic process failed to compile
  "SRC:/apps/vaporgui/QRange.ui"
into
  "SRC:/build/apps/vaporgui/vapor_autogen/include/ui_QRange.h"
included by
  "SRC:/apps/vaporgui/QRange.cpp"
Process failed with return value 127

Command
-------
/usr/local/VAPOR-Deps/current/bin/uic -o /home/li/VAPOR/build/apps/vaporgui/vapor_autogen/include/ui_QRange.h /home/li/VAPOR/apps/vaporgui/QRange.ui

Output
------
/usr/local/VAPOR-Deps/current/bin/uic: error while loading shared libraries: libicui18n.so.70: cannot open shared object file: No such file or directory

[shaomeng]

Update: update creating a symlink of libicui18n.so.70 the uic program starts to complain about other things. It feels that the bundled QT is very tied to the host operating system.

Update 2: this issue is better to be resolved by Jan 15 when Leigh Orf comes to visit us!

[NihanthCW]

Sam will try a few things with QTdir CMake option and update

[NihanthCW]

@sgpearse @shaomeng is this still relevant?

[sgpearse]

@NihanthCW Since we are not compiling any distributable binaries on Fedora, I do not think this is relevant.

[shaomeng]

Users like Leigh remain not be able to compile VAPOR. (Edit: Leigh uses the software VAPOR, at the same time he has a strong desire to dig into the code and develop new features/parameters to suit his specialized use cases.)

Do we care about that group of users? No then this is not relevant. Yes then this is relevant.

[sgpearse]

Do we care about that group of users?

@shaomeng We totally care about high impact users like Leigh, but we just employed the AppImage installer so that we can avoid the impossible task of deploying on every Linux distribution.

Have you asked Leigh what his reasons are for using Fedora, and whether using a more mainstream distribution like Ubuntu is not an option? It's not tenable to build our libraries for every Linux distribution.

[shaomeng]

Do we care about that group of users?

@shaomeng We totally care about high impact users like Leigh, but we just employed the AppImage installer so that we can avoid the impossible task of deploying on every Linux distribution.

Maybe it helps to differentiate users like Leigh and developers like Leigh. The AppImage doesn't help developers like Leigh at all. As a reminder, Leigh was very eager to experiment with different flow line settings programmaticly, but he wasn't able to because VAPOR doesn't build.

[sgpearse]

Not trying to be stubborn, but I need to know the answer to my previous question:

Have you asked Leigh what his reasons are for using Fedora, and whether using a more mainstream distribution like Ubuntu is not an option? It's not tenable to build our libraries for every Linux distribution.

[shaomeng]

Not trying to be stubborn, but I need to know the answer to my previous question:

Have you asked Leigh what his reasons are for using Fedora, and whether using a more mainstream distribution like Ubuntu is not an option? It's not tenable to build our libraries for every Linux distribution.

Maybe Leigh is a better person to answer this question?

Just to point out that Ubuntu is mostly 1-2 position higher than Fedora on this Linux popularity ranking: https://distrowatch.com/dwres.php?resource=popularity. The difference isn't significant enough to support that Ubuntu is more mainstream.

[NihanthCW]

Hi guys, based on what I'm hearing, I think this is just a matter of prioritization. We undoubtedly care about all our users but we might be forced to prioritize tasks based on the number of users it's going to impact.

On a side note: I do want to understand Qt related issues, in the context of accruing technical debt (later in a meeting). Cause, if this is something that would have other consequences in the future (such as the issue showing up on other platforms) it might be worthwhile to plan and fix it when we can rather than when we have to. For now, I'm ok leaving it open. Thanks for the discussion!