[osschar]

This Pull request:

Changes or fixes:

RenderCore, the WebGL engine of the REve client, is fetched at build time instead of
being bundled as a tarball in builtins/rendercore/, the way JSROOT and openui5 are.

• ExternalProject downloads RenderCore-<version>.tar.gz from lcgpackages first and
  from the GitHub release of UL-FRI-LGM/RenderCore second, and checks its SHA256. The
  version is 2.3.2. A RenderCore update is then two lines, the version and the hash.
• A build without a network takes the tarball from ROOT_DOWNLOAD_DIR, as for every
  builtin.
• The connection check runs before the builtin, as for openui5. The REve client has no web
  fallback for its engine, so without a connection the webgui configuration stops with an
  error.

The lcgpackages copy of RenderCore-2.3.2.tar.gz does not exist yet, so the GitHub URL
serves for now, as openui5 began. The builtins' tarballs there are uploaded by the ROOT
team (openui5 moved in 507d282); please advise how RenderCore's gets there, now and at
each release.

Can be backported to 6.42. If it is, the REve fixes for 6.42 that follow need no RenderCore
change; if it is not, they bring 2.3.2 as the tarball in the tree.

Checklist:

• tested changes locally
• updated the docs (if necessary)

Tested standalone with the builtin's CMakeLists.txt in a small project: the download
falls through from lcgpackages to the GitHub release, the hash matches and 41 files land in
ui5/eve7/rcore; with the tarball placed in ROOT_DOWNLOAD_DIR nothing is downloaded.

[github-actions]

Test Results

    22 files      22 suites   3d 14h 6m 54s ⏱️
 3 884 tests  3 883 ✅ 0 💤 1 ❌
76 046 runs  76 045 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 93bcea5.

[linev]

We need to introduce builtins_rendercore option - same as builtins_jsoot.
So one can clearly can enable/disable it.
If option will be disabled when webgui and root7 on - one issue error and propose either disable root7 or enable builtins_rendercore

[osschar]

Added the option builtin_rendercore.

It defaults to ON, unlike builtin_jsroot and builtin_openui5: REve has no web location to fall back to when the builtin is off, so an OFF default would stop every plain configure with webgui and root7 on.

With the option OFF while both are on, the configuration stops with "REve needs RenderCore: enable builtin_rendercore or disable root7".

The CI global config got builtin_rendercore=ON, since it lists every option.

A web fallback like JSROOT's would need RenderCore hosted at root.cern and the eve7 client's import redirected there; that is not in this PR.

One thing I noticed on the way: the HOTFIX_BUILD_FLAGS report at SearchInstalledSoftware.cmake:311 runs before the jsroot, mathjax and openui5 blocks, so the flags they append are never printed.

[osschar]

Looking at all this ... shouldn't we also put a switch on eve7? Something like this + all the logick of on-off-if-else-error:

ROOT_BUILD_OPTION(eve7 ON "Build REve, the web event display (requires webgui, root7 and geom; downloads RenderCore at build time)")

forced OFF when webgui, root7 or geom is off, as qt6web and cefweb are without webgui. graf3d/eve7 and the RenderCore block then hang off eve7, builtin_rendercore stays as it is, and the advice becomes "disable eve7" instead of "disable root7".

If you agree, I add it to the PR, squashing the commits (or not).