Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build fails: CMake Errors on 3rdparty - V 4.4.2 -D BUILD_SHARED_LIBS=OFF , no patches in use. #3718

Open
Chewbakka-Wakka opened this issue Mar 29, 2024 · 5 comments
Labels

Comments

@Chewbakka-Wakka
Copy link

CMake Errors on 3rdparty - V 4.4.2 - no patches in use.

%cmake
<------>-D BUILD_SHARED_LIBS=OFF
<------>-D BUILD_TESTING=ON
<------>-D CONFIGURE_WZ_COMPILER_WARNINGS=OFF
<------>-D ENABLE_DISCORD=OFF
<------>-D FMT_INSTALL=OFF
<------>-D FMT_SYSTEM_HEADERS=ON
<------>-D SKIPPED_DOC_GENERATION=OFF
<------>-D WZ_DISTRIBUTOR="G2V"
<------>-D WZ_ENABLE_WARNINGS_AS_ERRORS=OFF
<------>%{nil}
%cmake_build

I have utf8proc-devel installed, along with the rest.

-- Found Miniupnpc: /usr/include/miniupnpc (found suitable version "17", minimum required is "9")
CMake Error at 3rdparty/CMakeLists.txt:4 (add_subdirectory):
The source directory

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/3rdparty/utf8proc

does not contain a CMakeLists.txt file.

CMake Error at 3rdparty/CMakeLists.txt:5 (set_property):
set_property could not find TARGET utf8proc. Perhaps it has not yet been
created.

CMake Error at 3rdparty/CMakeLists.txt:7 (add_subdirectory):
The source directory

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/3rdparty/launchinfo

does not contain a CMakeLists.txt file.

CMake Error at 3rdparty/CMakeLists.txt:8 (set_property):
set_property could not find TARGET launchinfo. Perhaps it has not yet been
created.

CMake Error at 3rdparty/CMakeLists.txt:10 (add_subdirectory):
The source directory

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/3rdparty/fmt

does not contain a CMakeLists.txt file.

CMake Error at 3rdparty/CMakeLists.txt:11 (set_property):
set_property could not find TARGET fmt. Perhaps it has not yet been
created.

CMake Error at 3rdparty/CMakeLists.txt:29 (add_subdirectory):
The source directory

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/3rdparty/re2

does not contain a CMakeLists.txt file.

CMake Error at 3rdparty/CMakeLists.txt:30 (target_include_directories):
Cannot specify include directories for target "re2" which is not built by
this project.

CMake Error at 3rdparty/CMakeLists.txt:33 (set_property):
set_property could not find TARGET re2. Perhaps it has not yet been
created.

CMake Error at 3rdparty/CMakeLists.txt:34 (set_property):
set_property could not find TARGET re2. Perhaps it has not yet been
created.

CMake Error at 3rdparty/CMakeLists.txt:35 (set_property):
set_property could not find TARGET re2. Perhaps it has not yet been
created.

CMake Error at 3rdparty/CMakeLists.txt:37 (add_subdirectory):
The source directory

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/3rdparty/EmbeddedJSONSignature

does not contain a CMakeLists.txt file.

CMake Error at 3rdparty/CMakeLists.txt:38 (set_property):
set_property could not find TARGET EmbeddedJSONSignature. Perhaps it has
not yet been created.

-- Found SQLite3: /usr/include (found suitable version "3.45.2", minimum required is "3.14")
CMake Error at 3rdparty/CMakeLists.txt:57 (add_subdirectory):
The source directory

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/3rdparty/SQLiteCpp

does not contain a CMakeLists.txt file.

CMake Error at 3rdparty/CMakeLists.txt:58 (set_property):
set_property could not find TARGET SQLiteCpp. Perhaps it has not yet been
created.

CMake Error at 3rdparty/CMakeLists.txt:84 (add_subdirectory):
The source directory

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/3rdparty/quickjs-wz

does not contain a CMakeLists.txt file.

CMake Error at 3rdparty/CMakeLists.txt:85 (set_property):
set_property could not find TARGET quickjs. Perhaps it has not yet been
created.

-- Pre-installed basisu tool not found - attempting to build for host system
-- The C compiler identification is GNU 14.0.1
-- The CXX compiler identification is GNU 14.0.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /usr/share/cmake/Modules/ExternalProject.cmake:3259 (message):
No download info given for 'basisuExecutable' and its source directory:

/home/ss/rpmbuild/BUILD/warzone2100-4.4.2/x86_64-redhat-linux-gnu/3rdparty/basis_universal_host_tool/basis_universal_src

is not an existing non-empty directory. Please specify one of:

  • SOURCE_DIR with an existing non-empty directory
  • DOWNLOAD_COMMAND
  • URL
  • GIT_REPOSITORY
  • SVN_REPOSITORY
  • HG_REPOSITORY
  • CVS_REPOSITORY and CVS_MODULE
    Call Stack (most recent call first):
    /usr/share/cmake/Modules/ExternalProject.cmake:4445 (_ep_add_download_command)
    CMakeLists.txt:21 (ExternalProject_Add)

-- Configuring incomplete, errors occurred!
CMake Error at 3rdparty/CMakeLists.txt:124 (message):
Failed to configure basis_universal_host_build

-- Configuring incomplete, errors occurred!

@past-due
Copy link
Member

Looks like you need to init git submodules.

See: https://github.com/Warzone2100/warzone2100?tab=readme-ov-file#how-to-build

@Chewbakka-Wakka
Copy link
Author

Chewbakka-Wakka commented Mar 31, 2024

Neglected to mention, I wish to not use anything from 3rd party thus the use of "-D BUILD_SHARED_LIBS=OFF"
As I have SQLite3, utf8proc and all the other build deps installed. Is it possible to build without the use of those submodules pointing to 3rd party?

@past-due
Copy link
Member

Is it possible to build without the use of those submodules pointing to 3rd party?

Not all of them, no. As several of them have WZ-specific patches, are configured specifically for WZ, or are things where all builds should be using the same versions (glad, glm, inih, quickjs-wz, etc).

@mirror176
Copy link

Is there a clear document or list of when the third party modules are customized, brought in because a version must be used by all players, or is just brought in for convenience? I browsed a bit before previously but didn't yet see an easier way besides just scrolling through all of the commits to look for such changes.

I've noticed a growing trend of programs I looked at pulling in their own copies of 3rd party code when it isn't customized and is not there just because an outdated library is in use until modifying code to use the newer version properly.

On FreeBSD we normally prefer the non-customized libraries be non-bundled since build time is normally reduced when the library is not rebuilt for every program using it, any patching effort can take place in one location instead of being manually repeated for each program, and tracking/updating security issues is easier when all consumers don't have to be individually checked/reviewed.

Not a complaint by any means as I have usually noticed warzone2100 is more up to date on libraries rather than less and review has helped me find more up to date copies than what my system currently offered so its not like they have been left on old/outdated/buggy versions for years (at lest among my searches). I'd still prefer to unbundle as much as possible when viable for the reasons stated above.

@past-due
Copy link
Member

past-due commented Apr 14, 2024

Is there a clear document or list of when the third party modules are customized, brought in because a version must be used by all players, or is just brought in for convenience? I browsed a bit before previously but didn't yet see an easier way besides just scrolling through all of the commits to look for such changes.

There is no such document, however generally-speaking: if we rely on a library, we don’t need to customize it, it isn’t header-only, and we can relatively easily support multiple versions, it won’t be in the 3rdparty submodules and we will use the normal processes to find and link to a system install. (The main exception to this is miniupnpc, but as noted below the buildsystem will automatically link to system miniupnpc - if available - over the in-tree version.)

Theoretically, you could be able to use “system” versions of:

  • SQLiteCpp (although we will only test with the version we bundle, which we usually keep up-to-date)
  • date (although this is header-only)
  • miniupnpc
    • this is already explicitly supported by the CMake buildsystem - just ensure you have the proper library installed and it should be used automatically instead of the in-tree version, see:

      warzone2100/CMakeLists.txt

      Lines 859 to 863 in 2a60e34

      # Attempt to find Miniupnpc (minimum supported API version = 9)
      # NOTE: This is not available on every platform / distro
      find_package(Miniupnpc 9)
      if(MINIUPNPC_FOUND)
      set(WZ_USE_IMPORTED_MINIUPNPC ON)
      )

And some things you should definitely always use the bundled versions of are:

  • EmbeddedJSONSignature (this was essentially written for this project, but was packaged as a submodule in case there might be other uses for it)
  • basis_universal (we really want to use the latest bits for this)
  • glad (this is specifically customized for WZ)
  • glm (various versions have had bugs or changed behavior - we test with the version of this we bundle, which is usually far more up to date than most packages)
  • inih (has WZ modifications)
  • launchinfo (another set of code written for this project, but packaged as a submodule for possible additional use)
  • quickjs-wz (this is heavily customized for WZ, and the exact same bits must be used)

nlohmann::json could theoretically be some system version of this header-only lib, although we’re using the absolute latest, expect additional files present like the fwd headers, and may rely on new changes / features as new versions are released.

I've noticed a growing trend of programs I looked at pulling in their own copies of 3rd party code when it isn't customized and is not there just because an outdated library is in use until modifying code to use the newer version properly.

We do largely try to avoid this (and there is, of course, a long list of dependencies that must be pre-installed beyond anything in 3rdparty), but there have been cases where we’ve had to make customizations or rely on specific behavior - or where we actually want to rely on having a specific version (usually the latest version, which many distros may take their time on shipping).

On FreeBSD we normally prefer the non-customized libraries be non-bundled since build time is normally reduced when the library is not rebuilt for every program using it, any patching effort can take place in one location instead of being manually repeated for each program, and tracking/updating security issues is easier when all consumers don't have to be individually checked/reviewed.

Not a complaint by any means as I have usually noticed warzone2100 is more up to date on libraries rather than less and review has helped me find more up to date copies than what my system currently offered so its not like they have been left on old/outdated/buggy versions for years (at lest among my searches). I'd still prefer to unbundle as much as possible when viable for the reasons stated above.

I can absolutely appreciate this, and I think we’ve strived to have a good balance of this. The main thing I’d currently recommend is using system miniupnpc, which - assuming FreeBSD ships it and you have it installed - WZ’s buildsystem should automatically use for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants