search

vsg-dev / vsgFramework

Framework for building VulkanScenGraph related projects together
MIT License
10 stars 7 forks source link

Cache error on build in Windows #5

Closed sbrkopac closed 2 years ago

sbrkopac commented 2 years ago

When building I get the following errors. Doesn't look like they are critical errors as some parts of VSG get built.

My testing was spurred from this thread: https://groups.google.com/g/vsg-users/c/VSMZFJdQFAM

robertosfield commented 2 years ago

@sbrkopac I've now merged with the respective masters the FetchContent support into the various VSG projects so vsgFramework should work out of the box using FetchContent. It builds fine for me under Linux, but would love to know the current status under Windows. Do the above issues still persist?

ahoarau commented 2 years ago

@robertosfield The configure step fails on windows: image

robertosfield commented 2 years ago

Do you have OpenSceneGraph installed on your system? If you want to build osg2vsg then this is a pre-requisite.

What happens when you disable to build of osg2vsg via CMake?

ahoarau commented 2 years ago

It works ! It would be great to have the default configuration being without any external library - listing all cmake options in the file itself does not come naturally for some people

robertosfield commented 2 years ago

On Fri, 21 Oct 2022 at 11:05, Antoine Hoarau @.***> wrote:

It works ! It would be great to have the default configuration being without any external library - listing all cmake options in the file itself does not come naturally for some people

vsgFramework has been experimental so far - it's been used to shake down the VSG and other component libraries when using with submodules and FetchContent and to prove the concept of building components together.

vsgFramework has not yet been refined in its own right, enabling more components that would be appropriate by default is one area. I think adding checks for dependencies like OpenSceneGraph before enabling osg2vsg might be one thing to add.

However, in the end it's a template for others to use/learn from so they can see how to use CMake to pull in component libraries. It can be used as a template so developers can use it for their own versions easily. Long term I see vsgFramework as a starting place for developers that wish to build component libraries. Other users will prefer to build things in other ways and that's fine.

Message ID: @.***>

ahoarau commented 2 years ago

vsgFramework has not yet been refined in its own right, enabling more components that would be appropriate by default is one area. I think adding checks for dependencies like OpenSceneGraph before enabling osg2vsg might be one thing to add.

The deterministic behavior of having something at ON fail when the dep is not found is better IMO. A message listing the options at the beginning of the cmake configuration could be useful though + when the dep is not found, issue a readable message (at least better than the default cmake error that confuses people). That would reconciliate first-users (easy/fast first build) and package managers (deterministic builds).

However, in the end it's a template for others to use/learn from so they can see how to use CMake to pull in component libraries. It can be used as a template so developers can use it for their own versions easily. Long term I see vsgFramework as a starting place for developers that wish to build component libraries. Other users will prefer to build things in other ways and that's fine.

That is a good place to start dev with vsg

robertosfield commented 2 years ago

I have made the compile of osg2vsg dependent of a find_package(OpenSceneGraph QUIET) being successful so we shouldn't see build errors when external dependencies aren't found. The change is in vsgFramework master, with commit : 61b39e3577daf0a0459e975fa61b5748a42b933c