VulkanSceneGraph icon indicating copy to clipboard operation
VulkanSceneGraph copied to clipboard

Unable to use CMake FetchContent

Open sbrkopac opened this issue 2 years ago • 37 comments

Describe the bug Unable to use the FetchContent module to include VSG into a local project. There is also some clashing in the namespace such as "clobber".

To Reproduce This commit contains an example of how to enable an option that should include VSG as a proper target.

Expected behavior During configuration VSG should build and then be available as a target in CMake.

Additional context I haven't had a chance to dig into this yet.

The following REQUIRED packages have been found:

 * Vulkan (required version >= 1.2.162.0)
 * Threads

-- The following OPTIONAL packages have not been found:

 * vsg_glslang

CMake Error at CMakeLists.txt:40 (find_package):
  By not providing "Findvsg.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "vsg", but
  CMake did not find one.

  Could not find a package configuration file provided by "vsg" with any of
  the following names:

    vsgConfig.cmake
    vsg-config.cmake

  Add the installation prefix of "vsg" to CMAKE_PREFIX_PATH or set "vsg_DIR"
  to a directory containing one of the above files.  If "vsg" provides a
  separate development package or SDK, be sure it has been installed.

sbrkopac avatar May 17 '22 21:05 sbrkopac

I haven't look at this yet, so you have any further insights to what the issue is and what we'll need to amend to add support for FetchContent?

robertosfield avatar Jun 29 '22 15:06 robertosfield

@sbrkopac today we got a PR related to building the VSG as part of another project #483, any chance that will help with the issues you've seen with FetchContent?

robertosfield avatar Jul 07 '22 16:07 robertosfield

Hey Robert, I did see it. I'm hoping to find some time today to review. I'll get back to you.

sbrkopac avatar Jul 07 '22 16:07 sbrkopac

I dont know how much my PR will help with FetchContent but it helps with the add_subdirectory case when using VSG as git submodule for example.

Just to manage expectations.

WSSDude avatar Jul 08 '22 06:07 WSSDude

As a first step to getting some insight to the issues being tackled in FetchContent and the submodule issue I've done some testing with vsgFramework, I need to make a few updates as I hadn't touch it since last year. To help I've just checked in the addition of ability to edit repository URL and tag/branch:

vsgFramework

@sbrkopac and @WSSDude420 do you have a repo that uses FetchContent or submodule with the VSG that I can check out and compare the experience?

robertosfield avatar Jul 08 '22 15:07 robertosfield

None real example apart from the project I mentioned which I cannot make public.

Minimal steps for submodule at least would be to have VSG in .gitmodules

[submodule "thirdparty/VulkanSceneGraph"]
	path = thirdparty/VulkanSceneGraph
	url = [email protected]:vsg-dev/VulkanSceneGraph.git

This should checkout VSG into thirdparty/VulkanSceneGraph

Now just make CMakeLists.txt in root where you have the .gitmodules and have it have add_subdirectory(thirdparty/VulkanSceneGraph) somewhere before you add your targets, linking with VSG after it like this.

add_subdirectory(thirdparty/VulkanSceneGraph)

add_executable(vsg-test
   # sources
)
target_link_libraries(vsg-test
  PUBLIC
    vsg
)

This is like totally basic setup I can think of for this particular case.

WSSDude avatar Jul 08 '22 15:07 WSSDude

Actually, it just came to my mind that MyFirstVSGApplication project may be a great candidate to try to apply this to.

It is minimal and does not currently include VSG in any way apart from trying to find it. https://github.com/vsg-dev/MyFirstVsgApplication/blob/master/CMakeLists.txt

Just replace find_package there with mentioned add_subdirectory and link with vsg instead of vsg::vsg

WSSDude avatar Jul 08 '22 15:07 WSSDude

Did just that in the meantime, can be found here. https://github.com/WSSDude420/vsg-test-submodule

WSSDude avatar Jul 08 '22 15:07 WSSDude

On Fri, 8 Jul 2022 at 16:58, Andrej Redeky @.***> wrote:

Did just that in the meantime, can be found here. https://github.com/WSSDude420/vsg-test-submodule

Thanks for creating ths. Does this repo fail with VSG master, but succeed for your PR applied?

I have currently investigating a regression elsewhere in the VSG, once that's resolved I'll have a look. If PR works and looks clearn I'll apply it to vsgXchange, vsgImGui and vsgQt.

Message ID: @.***>

robertosfield avatar Jul 08 '22 16:07 robertosfield

Yeah with my PR applied, this should produce solution without issues. It is not applied inside there though, just fair warning. I used master there from here.

WSSDude avatar Jul 08 '22 16:07 WSSDude

@WSSDude420 I have forked your vsg-test-submodule project. I had to tweak the .gitmodules file to get it to pull in the VSG but once that was done it all built without a hitch. Even without your mods the VSG.

The change I made was:

diff --git a/.gitmodules b/.gitmodules
index da58518..53d3bf5 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,3 @@
 [submodule "thirdparty/vsg"]
        path = thirdparty/vsg
-       url = [email protected]:vsg-dev/VulkanSceneGraph.git
+       url = https://github.com/vsg-dev/VulkanSceneGraph.git

What problem should I be seeing without your PR merged?

robertosfield avatar Jul 08 '22 17:07 robertosfield

Did it now? Hm... When I tried to use it with Visual Studio as CMake project, it had empty SOURCES and HEADERS variables, making vsg effectively empty. I was unable to use it without these changes.

CMAKE_SOURCE_DIR was resolving to root directory so in case of the above sample, it happened to be trying to look for src/vsg but it was in thirdparty/vsg/src/vsg from that path.

I was printing them via message() to see their values, at it was only possible culprit. Dont know now then what is the issue tbh.

Same case with BINARY.

WSSDude avatar Jul 08 '22 18:07 WSSDude

Maybe it is some issue with that setup? Will test it when I can with generating project from CMake GUI.

WSSDude avatar Jul 08 '22 18:07 WSSDude

OK, exact environment this 100% fails with master and succeeds with PR:

  • Visual Studio 2022 with CMake projects module installed
  • Open sample via right-click inside the folder in Windows explorer and choosing Open with Visual Studio
  • This opens it as CMake project
  • It configures just fine
  • Trying to compile it fails
>------ Build All started: Project: vsg-test-submodule, Configuration: x64-Debug ------
  [1/195] Building CXX object CMakeFiles\myfirstvsgapplication.dir\src\main.cpp.obj
  FAILED: CMakeFiles/myfirstvsgapplication.dir/src/main.cpp.obj 
  C:\PROGRA~1\MIB055~1\2022\PROFES~1\VC\Tools\MSVC\1432~1.313\bin\Hostx64\x64\cl.exe  /nologo /TP  -IC:\git\vsg-test-submodule\include -IC:\git\vsg-test-submodule\out\build\x64-Debug\include -external:I C:\VulkanSDK\1.3.204.1\Include -external:W0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG -std:c++17 /showIncludes /FoCMakeFiles\myfirstvsgapplication.dir\src\main.cpp.obj /FdCMakeFiles\myfirstvsgapplication.dir\ /FS -c C:\git\vsg-test-submodule\src\main.cpp
C:\git\vsg-test-submodule\src\main.cpp(1): fatal error C1083: Cannot open include file: 'vsg/all.h': No such file or directory
  [2/195] Building CXX object thirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\Allocator.cpp.obj
  FAILED: thirdparty/vsg/src/vsg/CMakeFiles/vsg.dir/core/Allocator.cpp.obj 
  C:\PROGRA~1\MIB055~1\2022\PROFES~1\VC\Tools\MSVC\1432~1.313\bin\Hostx64\x64\cl.exe  /nologo /TP  -IC:\git\vsg-test-submodule\include -IC:\git\vsg-test-submodule\out\build\x64-Debug\include -external:I C:\VulkanSDK\1.3.204.1\Include -external:W0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG /bigobj /MP -std:c++17 /showIncludes /Fothirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\Allocator.cpp.obj /Fdthirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\vsg.pdb /FS -c C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\Allocator.cpp
C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\Allocator.cpp(13): fatal error C1083: Cannot open include file: 'vsg/core/Allocator.h': No such file or directory
  [3/195] Building CXX object thirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\Auxiliary.cpp.obj
  FAILED: thirdparty/vsg/src/vsg/CMakeFiles/vsg.dir/core/Auxiliary.cpp.obj 
  C:\PROGRA~1\MIB055~1\2022\PROFES~1\VC\Tools\MSVC\1432~1.313\bin\Hostx64\x64\cl.exe  /nologo /TP  -IC:\git\vsg-test-submodule\include -IC:\git\vsg-test-submodule\out\build\x64-Debug\include -external:I C:\VulkanSDK\1.3.204.1\Include -external:W0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG /bigobj /MP -std:c++17 /showIncludes /Fothirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\Auxiliary.cpp.obj /Fdthirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\vsg.pdb /FS -c C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\Auxiliary.cpp
C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\Auxiliary.cpp(13): fatal error C1083: Cannot open include file: 'vsg/core/Auxiliary.h': No such file or directory
  [4/195] Building CXX object thirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\ConstVisitor.cpp.obj
  FAILED: thirdparty/vsg/src/vsg/CMakeFiles/vsg.dir/core/ConstVisitor.cpp.obj 
  C:\PROGRA~1\MIB055~1\2022\PROFES~1\VC\Tools\MSVC\1432~1.313\bin\Hostx64\x64\cl.exe  /nologo /TP  -IC:\git\vsg-test-submodule\include -IC:\git\vsg-test-submodule\out\build\x64-Debug\include -external:I C:\VulkanSDK\1.3.204.1\Include -external:W0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG /bigobj /MP -std:c++17 /showIncludes /Fothirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\ConstVisitor.cpp.obj /Fdthirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\vsg.pdb /FS -c C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\ConstVisitor.cpp
C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\ConstVisitor.cpp(13): fatal error C1083: Cannot open include file: 'vsg/all.h': No such file or directory
  [5/195] Building CXX object thirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\External.cpp.obj
  FAILED: thirdparty/vsg/src/vsg/CMakeFiles/vsg.dir/core/External.cpp.obj 
  C:\PROGRA~1\MIB055~1\2022\PROFES~1\VC\Tools\MSVC\1432~1.313\bin\Hostx64\x64\cl.exe  /nologo /TP  -IC:\git\vsg-test-submodule\include -IC:\git\vsg-test-submodule\out\build\x64-Debug\include -external:I C:\VulkanSDK\1.3.204.1\Include -external:W0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG /bigobj /MP -std:c++17 /showIncludes /Fothirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\core\External.cpp.obj /Fdthirdparty\vsg\src\vsg\CMakeFiles\vsg.dir\vsg.pdb /FS -c C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\External.cpp
C:\git\vsg-test-submodule\thirdparty\vsg\src\vsg\core\External.cpp(13): fatal error C1083: Cannot open include file: 'vsg/core/ConstVisitor.h': No such file or directory

......

Build All failed.

WSSDude avatar Jul 09 '22 10:07 WSSDude

Printing paths as I mentioned via message inside CMakeLists of VSG, I found out the issues I wrote about yesterday.

I just tested using generated solution via CMake GUI and same happened with it, so this doesnt seem to be just Visual Studio issue for me at least :/

WSSDude avatar Jul 09 '22 10:07 WSSDude

Thanks for the testing and info.

When you run CMake to generate the build system and automatically generated headers where does it put the generated header, libs and dlls?

On my linux system I tried in source and out of source builds and didn't provoke a failure, When I get back to my dev system I'll see if there are any already installed headers that might be being picked up.

robertosfield avatar Jul 09 '22 10:07 robertosfield

On Sat, 9 Jul 2022 at 11:59, Robert Osfield @.***> wrote:

On my linux system I tried in source and out of source builds and didn't provoke a failure, When I get back to my dev system I'll see if there are any already installed headers that might be being picked up

I've scrubbed all my previously installed VSG headers, libs and cmake files and then did an in source and an out of source build of vsg-test-submodule.

If I do a make VERBOSE=1 you can see the include paths used in the build, and snippet of which:

[ 0%] Building CXX object thirdparty/vsg/src/vsg/CMakeFiles/vsg.dir/core/Allocator.cpp.o cd /home/robert/Dev/temp/build/thirdparty/vsg/src/vsg && /bin/c++ -DGLSLANG_EShLangRayGen -DGLSLANG_ResourceLimits_maxDualSourc eDrawBuffersEXT -DHAS_GLSLANG -I/home/robert/Dev/temp/vsg-test-submodule/thirdparty/vsg/src/vsg/../../include -I/home/robert/De v/temp/build/thirdparty/vsg/src/vsg/../../include -isystem /home/robert/3rdParty/VulkanSDK/1.3.216.0/x86_64/include -O3 -DNDEBU G -fPIC -Wall -Wparentheses -Wno-long-long -Wno-import -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wmaybe-uninitialized - Wshadow -Wunused -Wno-misleading-indentation -Wextra -std=gnu++17 -o CMakeFiles/vsg.dir/core/Allocator.cpp.o -c /home/robert/De v/temp/vsg-test-submodule/thirdparty/vsg/src/vsg/core/Allocator.cpp [ 1%] Building CXX object thirdparty/vsg/src/vsg/CMakeFiles/vsg.dir/core/Auxiliary.cpp.o cd /home/robert/Dev/temp/build/thirdparty/vsg/src/vsg && /bin/c++ -DGLSLANG_EShLangRayGen -DGLSLANG_ResourceLimits_maxDualSourc eDrawBuffersEXT -DHAS_GLSLANG -I/home/robert/Dev/temp/vsg-test-submodule/thirdparty/vsg/src/vsg/../../include -I/home/robert/De v/temp/build/thirdparty/vsg/src/vsg/../../include -isystem /home/robert/3rdParty/VulkanSDK/1.3.216.0/x86_64/include -O3 -DNDEBU G -fPIC -Wall -Wparentheses -Wno-long-long -Wno-import -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wmaybe-uninitialized - Wshadow -Wunused -Wno-misleading-indentation -Wextra -std=gnu++17 -o CMakeFiles/vsg.dir/core/Auxiliary.cpp.o -c /home/robert/De v/temp/vsg-test-submodule/thirdparty/vsg/src/vsg/core/Auxiliary.cpp

So both the original source include directory and the build include directory are specified. This is my cmake version.

$ cmake --version cmake version 3.18.4

It's odd that Windows would do something different with include paths. I don't have WIndows to do testing so will have to defer to those under Windows to provide insight.

robertosfield avatar Jul 09 '22 12:07 robertosfield

I was testing with CMake 3.23.2 Just as a sanity check, I downloaded older release corresponding to yours from their archive, but I still get same output with 3.18.4 so this does not seem to be related to CMake version 🤔

WSSDude avatar Jul 09 '22 13:07 WSSDude

Hi Andrej,

On Sat, 9 Jul 2022 at 14:36, Andrej Redeky @.***> wrote:

I was testing with CMake 3.23.2 Just as a sanity check, I downloaded older release corresponding to yours from their archive, but I still get same output with 3.18.4 so this does not seem to be related to CMake version 🤔

Sorry for all these iterations, it's turning out to be hard to figure out what is going on with the different systems.

Could you post your CMakeCache.txt file for when it fails and when it works with the PR change.

The reason why I want to establish what is going on is that will help is figure out the best fix and whether there will be knock on effects.

I'm thinking about creating a vsgFramework version using submodule, and another using FetchContent.

Message ID: @.***>

robertosfield avatar Jul 09 '22 14:07 robertosfield

Sure, here you go CMakeCache-failing.txt CMakeCache-success.txt

WSSDude avatar Jul 09 '22 14:07 WSSDude

On Sat, 9 Jul 2022 at 15:46, Andrej Redeky @.***> wrote:

Sure, here you go CMakeCache-failing.txt https://github.com/vsg-dev/VulkanSceneGraph/files/9077352/CMakeCache-failing.txt CMakeCache-success.txt https://github.com/vsg-dev/VulkanSceneGraph/files/9077354/CMakeCache-success.txt

Thanks. Just run these two files in xxdiff and the only differences I've seen so far look to be all related to finding glslang.

This is curious, and obviously a big hint, but it's not what I was expecting, and not something that tells me what part is the bit that fails yet, and why the changes fix them. We have to be getting close though.

Message ID: @.***>

robertosfield avatar Jul 09 '22 14:07 robertosfield

I have merge @WSSDude420 PR as a branch WSSDude420-Fix_inclusion_in_other_CMake_project so we can test it from there.

@sbrkopac Could you test this branch against your FetchContent usage.

Ideally I'd like to create a set of FetchContent, submodule and local clone usage cases.

robertosfield avatar Jul 12 '22 10:07 robertosfield

I was just doing house keep on vsg-dev projects and came across this old FetchContent branch of vsgFramework:

https://github.com/vsg-dev/vsgFramework/tree/FetchContent

I tried use VSG master and the WSSDude420-Fix_inclusion_in_other_CMake_project in the FetchConent line for the VSG but get errors regardless. I get errors in the from:

CMake Error at vsgConfig.cmake:1 (include):
  include could not find load file:

    /home/robert/Dev/vsgFramework/vsgMacros.cmake
Call Stack (most recent call first):
  _deps/vsgexamples-src/CMakeLists.txt:24 (find_package)


-- Found Vulkan: /home/robert/3rdParty/VulkanSDK/1.3.216.0/x86_64/lib/libvulkan.so (Required is at least version "1.1.70.0") 
CMake Error at vsgConfig.cmake:22 (include):
  include could not find load file:

    /home/robert/Dev/vsgFramework/vsgTargets.cmake
Call Stack (most recent call first):
  _deps/vsgexamples-src/CMakeLists.txt:24 (find_package)


CMake Error at _deps/vsg-src/cmake/vsgMacros.cmake:236 (add_custom_target):
  add_custom_target cannot create target "clang-format" because another
  target with the same name already exists.  The existing target is a custom
  target created in source directory
  "/home/robert/Dev/vsgFramework/_deps/vsg-src".  See documentation for
  policy CMP0002 for more details.
Call Stack (most recent call first):
  _deps/vsgexamples-src/CMakeLists.txt:38 (vsg_add_target_clang_format)


CMake Error at _deps/vsg-src/cmake/vsgMacros.cmake:249 (add_custom_target):
  add_custom_target cannot create target "clobber" because another target
  with the same name already exists.  The existing target is a custom target
  created in source directory "/home/robert/Dev/vsgFramework/_deps/vsg-src".
  See documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
  _deps/vsgexamples-src/CMakeLists.txt:45 (vsg_add_target_clobber)

I don't know if it's down to problems in the rather old vsgFramework FetchContent branch, or something problematic with using vsgMacros.cmake. I'm open to suggests on how best to resolve these issues.

robertosfield avatar Jul 12 '22 11:07 robertosfield

Looks like there are name clashes for a few targets, similar to this PR: https://github.com/vsg-dev/VulkanSceneGraph/pull/329

This is the configuration.txt that is output from CMake using CMakeLists.txt. Then when I try to build it I get build-errors.txt.

Using WSSDude420-Fix_inclusion_in_other_CMake_project I still get configuration errors but the build succeeds.

I'm not sure if the error is the way VSG is configured or the macros - the targets just aren't available to CMake so it can't link to my example problem.

sbrkopac avatar Jul 12 '22 22:07 sbrkopac

Thanks for the testing, recall of the PR - I'd forgotten that one. The collisions look to be related to the vsgMacros.cmake generated targets.

The configuration.text is 0 bytes, but I've been able to download the CMakeLists.txt and build-errors.txt.

I have used the MyFirstVsgApplication main.cpp and then ran cmake . on the CMakeLists.txt and it fails to set up the build system with VSG master or WSSDude420-Fix_inclusion_in_other_CMake_project. Console output from cmake . below.

$ cmake .
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /bin/cc - 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: /bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Reading 'vsg_...' macros from /home/robert/Contributors/SamBrkopac/_deps/vsg-src/cmake/vsgMacros.cmake - look there for documentation
-- Using Vulkan version check embedded in vsg
-- Found Vulkan: /home/robert/3rdParty/VulkanSDK/1.3.216.0/x86_64/lib/libvulkan.so (found suitable version "1.3.216", minimum required is "1.1.70.0")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
-- Found glslang: /home/robert/3rdParty/VulkanSDK/1.3.216.0/x86_64/lib/libglslang.a
-- Found PkgConfig: /bin/pkg-config (found version "0.29.2") 
-- Checking for module 'xcb'
--   Found xcb, version 1.14
-- Performing Test HAVE_CXX_ATOMIC_WITHOUT_LIB
-- Performing Test HAVE_CXX_ATOMIC_WITHOUT_LIB - Success
-- Performing Test GLSLANG_ResourceLimits_maxDualSourceDrawBuffersEXT
-- Performing Test GLSLANG_ResourceLimits_maxDualSourceDrawBuffersEXT - Success
-- Performing Test GLSLANG_EShLanguage_EShLangRayGen
-- Performing Test GLSLANG_EShLanguage_EShLangRayGen - Success
-- Performing Test GLSLANG_EShLanguage_EShLangRayGenNV
-- Performing Test GLSLANG_EShLanguage_EShLangRayGenNV - Success
-- The following OPTIONAL packages have been found:

 * vsg_glslang

-- The following REQUIRED packages have been found:

 * Vulkan (required version >= 1.1.70.0)
 * Threads
 * PkgConfig

-- Configuring done
CMake Error at CMakeLists.txt:15 (add_executable):
  Target "test" links to target "vsg::vsg" but the target was not found.
  Perhaps a find_package() call is missing for an IMPORTED target, or an
  ALIAS target is missing?


-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

robertosfield avatar Jul 13 '22 07:07 robertosfield

Sorry about the empty file, but your cmake output is essentially the exact same.

sbrkopac avatar Jul 13 '22 08:07 sbrkopac

On Wed, 13 Jul 2022 at 09:01, Sam Brkopac @.***> wrote:

Sorry about the empty file, but your cmake output is essentially the exact same.

I'm afraid I don't have enough experience with FetchContent to know where to start debugging it.

The multiple overlapping targets seems like an issue that all projects will have if you are pulling them in from submodules or FetchContent as they all will want to have build and install targets. Is there some mechanism in CMake for handling this? If so, is there a way it can be extended to custom targets like uninstall?

Message ID: @.***>

robertosfield avatar Jul 13 '22 08:07 robertosfield

I have returned to looking at @WSSDude420's proposed changes to the VSG, I have updated my clone of the vsg-test-submodule, adding osg2vsg, vsgXchange and vsgImGui as submodules and attempted a build:

https://github.com/robertosfield/vsg-test-submodule/

On running cmake within the vsg-test-submodule directory I get the error:

CMake Error at thirdparty/osg2vsg/CMakeLists.txt:85 (find_package):
  By not providing "Findvsg.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "vsg", but
  CMake did not find one.

  Could not find a package configuration file provided by "vsg" with any of
  the following names:

    vsgConfig.cmake
    vsg-config.cmake

  Add the installation prefix of "vsg" to CMAKE_PREFIX_PATH or set "vsg_DIR"
  to a directory containing one of the above files.  If "vsg" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!
See also "/home/robert/Dev/vsg-test-submodule/CMakeFiles/CMakeOutput.log".

Trying to run cmake from a vsg-test-submodule/build subdirectory fails with the same errors as well

I haven't modified osg2vsg, vsgXchange and vsgImGui with the same changes as applied to VSG, will updating these address this issue?

robertosfield avatar Aug 02 '22 17:08 robertosfield

Through today I've been trying to coax vsg-test-submodule into to building VulkanSceneGraph and vsgImGui as submodules. It works fine with VSG built on it's own, but as yet I haven't been able to get it to work but have git upon

https://github.com/robertosfield/vsg-test-submodule

Change vsgImGui and the VSG to use CMAKE_CURRENT_SOURCE_DIR and CMAKE_CURRENT_BINARY_DIR but this does help with these problems. The problems look to be an issue with vsgImGui looking for VSG cmake config scripts that haven't yet been built and installed in bin directory.

I don't know a way of working around this, I've tried various things but nothing has worked so far. I'm moving towards the opinion that getting the VSG and associated projects to all work together as git submodules is not possible, and CMake FetchContent and ExtternalProject

For now I'll switch to trying to get vsgFramework to work with both the FetchContent and ExternalProject approaches.

The problem make output warning output is from my vsg-test-submodule is:

vsgImGui CMake vsgImGui root dir CMAKE_SOURCE_DIR = /home/robert/Dev/vsg-test-submodule vsgImGui root dir CMAKE_BINARY_DIR = /home/robert/Dev/vsg-test-submodule vsgImGui root dir CMAKE_CURRENT_SOURCE_DIR = /home/robert/Dev/vsg-test-submodule/thirdparty/vsgImGui vsgImGui root dir CMAKE_CURRENT_BINARY_DIR = /home/robert/Dev/vsg-test-submodule/thirdparty/vsgImGui vsgImGui root dir CMAKE_MODULE_PATH = /home/robert/Dev/vsg-test-submodule/thirdparty/vsg/cmake;/home/robert/Dev/vsg-test-submodule/thirdparty/vsg/src/vsg vsgImGui root dir CMAKE_CURRENT_LIST_DIR = /home/robert/Dev/vsg-test-submodule/thirdparty/vsgImGui vsgImGui root dir CMAKE_CURRENT_LIST_FILE = /home/robert/Dev/vsg-test-submodule/thirdparty/vsgImGui/CMakeLists.txt CMake Error at thirdparty/vsg/src/vsg/vsgConfig.cmake:1 (include): include could not find requested file:

/home/robert/Dev/vsg-test-submodule/thirdparty/vsg/src/vsg/vsgMacros.cmake

Call Stack (most recent call first): thirdparty/vsgImGui/CMakeLists.txt:29 (find_package)

-- Using Vulkan version check embedded in vsg -- Found Vulkan: /home/robert/3rdParty/VulkanSDK/1.3.216.0/x86_64/lib/libvulkan.so (found suitable version "1.3.216", minimum required is "1.1.70.0") -- Found glslang: /home/robert/3rdParty/VulkanSDK/1.3.216.0/x86_64/lib/libglslang.a CMake Error at thirdparty/vsg/src/vsg/vsgConfig.cmake:22 (include): include could not find requested file:

/home/robert/Dev/vsg-test-submodule/thirdparty/vsg/src/vsg/vsgTargets.cmake

Call Stack (most recent call first): thirdparty/vsgImGui/CMakeLists.txt:29 (find_package)

CMake Error at thirdparty/vsg/cmake/vsgMacros.cmake:238 (add_custom_target): add_custom_target cannot create target "clang-format" because another target with the same name already exists. The existing target is a custom target created in source directory "/home/robert/Dev/vsg-test-submodule/thirdparty/vsg". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): thirdparty/vsgImGui/CMakeLists.txt:71 (vsg_add_target_clang_format)

CMake Error at thirdparty/vsg/cmake/vsgMacros.cmake:251 (add_custom_target): add_custom_target cannot create target "clobber" because another target with the same name already exists. The existing target is a custom target created in source directory "/home/robert/Dev/vsg-test-submodule/thirdparty/vsg". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): thirdparty/vsgImGui/CMakeLists.txt:76 (vsg_add_target_clobber)

CMake Error at thirdparty/vsg/cmake/vsgMacros.cmake:289 (add_custom_target): add_custom_target cannot create target "cppcheck" because another target with the same name already exists. The existing target is a custom target created in source directory "/home/robert/Dev/vsg-test-submodule/thirdparty/vsg". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): thirdparty/vsgImGui/CMakeLists.txt:77 (vsg_add_target_cppcheck)

CMake Error at thirdparty/vsg/cmake/vsgMacros.cmake:341 (add_custom_target): add_custom_target cannot create target "uninstall" because another target with the same name already exists. The existing target is a custom target created in source directory "/home/robert/Dev/vsg-test-submodule/thirdparty/vsg". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): thirdparty/vsgImGui/CMakeLists.txt:86 (vsg_add_target_uninstall)

-- The following REQUIRED packages have been found:

robertosfield avatar Aug 03 '22 14:08 robertosfield

Umm... vsgFramework master is now failing for me, while it was working previously. However, yesterday I upgraded my Kubuntu 21.10 distro to 22.04 so a more modern CMake version could be the reason for the change in behavior, and why I've had different results from above. The cmake version I now have is 3.22.1.

The errors looks similar to the problems with vsg-test-submodule test immediately above:

[ 44%] Performing update step for 'vsgXchange' HEAD is now at 80ae824 Added mention of osg2vsg [ 46%] No patch step for 'vsgXchange' [ 48%] Performing configure step for 'vsgXchange' CMake Error at /home/robert/Dev/vsgFramework/vsgConfig.cmake:1 (include): include could not find requested file:

/home/robert/Dev/vsgFramework/vsgMacros.cmake

Call Stack (most recent call first): CMakeLists.txt:21 (find_package)

CMake Error at /home/robert/Dev/vsgFramework/vsgConfig.cmake:22 (include): include could not find requested file:

/home/robert/Dev/vsgFramework/vsgTargets.cmake

Call Stack (most recent call first): CMakeLists.txt:21 (find_package)

CMake Error at /home/robert/Dev/vsgFramework/vsgConfig.cmake:1 (include): include could not find requested file:

/home/robert/Dev/vsgFramework/vsgMacros.cmake

Call Stack (most recent call first): /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /home/robert/Install/lib/cmake/osg2vsg/osg2vsgConfig.cmake:3 (find_dependency) CMakeLists.txt:24 (find_package)

CMake Error at /home/robert/Dev/vsgFramework/vsgConfig.cmake:22 (include): include could not find requested file:

/home/robert/Dev/vsgFramework/vsgTargets.cmake

Call Stack (most recent call first): /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /home/robert/Install/lib/cmake/osg2vsg/osg2vsgConfig.cmake:3 (find_dependency) CMakeLists.txt:24 (find_package)

CMake Error at CMakeLists.txt:39 (vsg_setup_build_vars): Unknown CMake command "vsg_setup_build_vars".

robertosfield avatar Aug 03 '22 15:08 robertosfield