[civetweb] download from GIT instead of bundle, bump from 1.16+ to latest master, and define proper CMake target

[ferdymercury]

Cleaned-up version of #21947

[dpiparo]

thanks for this sizable effort!

[dpiparo]

If everything works, and we go with this solution, we should perhaps move the source tarball to the LCG Packages, as all the others.

[ferdymercury]

If everything works, and we go with this solution, we should perhaps move the source tarball to the LCG Packages, as all the others.

Sounds good to me. In that case, it should be downloaded from commit civetweb/civetweb@588860e (no tagged version) and I guess upload it to LCG with name:

civetweb-1.16-588860.tar.gz

[github-actions]

Test Results

    23 files      23 suites   3d 18h 59m 57s ⏱️
 3 853 tests  3 853 ✅ 0 💤 0 ❌
79 408 runs  79 408 ✅ 0 💤 0 ❌

Results for commit 16ec94c.

♻️ This comment has been updated with latest results.

[linev]

@dpiparo @ferdymercury

Last point.

After the PR default config builtin_civetweb=OFF. If user does not enables it and system-wide civetweb not found or not sufficient building of THttpServer and all webgui components makes no big sense. One cannot use them without civetweb.

I propose to make hard condition. If http is enabled and civetweb not found one generate error with the message that http cannot be used without it. Either user should actively disable http or enable any of civetweb components.

[linev]

@ferdymercury

Last change which is necessary described in my comment: #22731 (comment)

One need either to have civetweb/builtin_civetweb or disable http.

But really grate job and grate effort!

[ferdymercury]

Either user should actively disable http or enable any of civetweb components.

What about if system-version is found but does not have the X_DOM_SOCKET enabled? Should then the CMake system automatically (silently) turn of the builtin_civetweb flag, or do we also want to force the user to actively enable -Dbuiltin_civetweb=ON

[linev]

What about if system-version is found but does not have the X_DOM_SOCKET enabled? Should then the CMake
system automatically (silently) turn of the builtin_civetweb flag,
or do we also want to force the user to actively enable -Dbuiltin_civetweb=ON

Yes, this is also the situation when error message must be shown and user actively should enable -Dbuiltin_civetweb=ON or disable http.

[ferdymercury]

@linev It seems opensuse16 machine is missing one of the packages ? I tried here: root-project/root-ci-images#141

  CMake Error at /usr/lib64/cmake/civetweb/civetweb-targets.cmake:106 (message):
    The imported target "civetweb::server" references the file
       "/usr/bin/civetweb"
    but this file does not exist.  Possible reasons include:
    * The file was deleted, renamed, or moved to another location.
    * An install or uninstall procedure did not complete successfully.
    * The installation package was faulty and contained
       "/usr/lib64/cmake/civetweb/civetweb-targets.cmake"
    but not all the files it references.
  Call Stack (most recent call first):
    /usr/lib64/cmake/civetweb/civetweb-config.cmake:57 (include)
    cmake/modules/SearchInstalledSoftware.cmake:539 (find_package)
    CMakeLists.txt:136 (include)