search

arrayfire / forge

High Performance Visualization
226 stars 48 forks source link

Please include glad directly into forge #236

Closed StefanBruens closed 1 year ago

StefanBruens commented 2 years ago

Current setup of glad dependency makes it unnecessary hard to build:

  1. forge expects a specific configuration, as can be found in arrayfire's glad repository. A vanilla upstream glad does not work, as that has to be integrated specifically, see e.g. https://github.com/Dav1dde/glad/issues/376#issuecomment-1209640818
  2. Offline builds expects a git clone, a snapshot downloaded from githup (e.g. https://github.com/arrayfire/glad/archive/refs/heads/master.tar.gz) does not work.

forge should either include the pregenerated glad sources as a git subproject, or use a plain upstream glad and configure it at build time.

9prady9 commented 2 years ago

Forge (ArrayFire also) uses a specific workflow for fetching dependencies like glad, glm etc. for building the concerned project. I believe it is better to be consistent on how CMake fetches dependencies if possible, which it is in the case of glad for forge/arrayfire. I am not a fan of including large source files into the repository, especially when CMake can help with the same. Also, please note that, all this dependency handling is taken care by the CMakeLists.txt without user invention. If that is not the case in your experience, please share the issue you have encountered.

forge should either include the pregenerated glad sources as a git subproject,

Sure, that is one way to do it. Again subtree is nothing but maintaining a copy of those sources in the downstream project which we want to avoid. We used to have similar dependencies as submodules, but we removed those in favor of CMake's fetch content which lets us handle the case of git not being available in offline builds.

or use a plain upstream glad and configure it at build time.

In a way, what's transpiring now is akin to the above suggestion. The difference being, we keep the glad sources that arrayfire and forge needs in separate repository and we re-use that directly in our CMake.

As far as the offline builds are concerned, every release of forge uploads a full code base of forge that includes the dependencies also as forge-full-x.x.x.tar.bz2 GitHub release asset.

I am not suggesting the workflow of arrayfire/forge is the best route but it definitely addresses the uses cases we want to handle.

9prady9 commented 1 year ago

Closing due to inactivity, please re-open if required after reviewing my above response.

StefanBruens commented 9 months ago

The "forge-full" tarball is broken - FetchContent_Populate, as called by fg_dep_check_and_populate requires a git checkout, i.e. including the ".git" directory.

Please try to build it without any network connection, it will fail with the following output:

[   14s] [ 11%] Creating directories for 'fg_glad-populate'
[   14s] [ 22%] Performing download step for 'fg_glad-populate'
[   14s] [ 33%] Performing disconnected update step for 'fg_glad-populate'
[   14s] CMake Error at /home/abuild/rpmbuild/BUILD/forge-1.0.8/build/extern/fg_glad-subbuild/fg_glad-populate-prefix/tmp/fg_glad-populate-gitupdate.cmake:34 (message):
[   14s]   Failed to get the hash for HEAD:
[   14s] 
[   14s]   fatal: not a git repository: '.git'
9prady9 commented 9 months ago

https://github.com/arrayfire/arrayfire/issues/3527#issuecomment-1882445456