BuildFlexibilty branches FetchContent and submodule

[Robert Osfield]

Hi All,

Before I f*cked up my right arm I had begun investigating reported issues with building VSG projects using CMake FetchContent and git submodules.  This is important for the future of the VSG as I've opted for a multiple project approach rather than a single uber project like I took with the OpenSceneGraph, so users need a way of picking the components they need and for them to build it in a unified and straight forward way such as illustrated by the vsgFramework

The  work was managed within a series of BuildFlexibilty branches of all the core VSG projects.  This work is not pretty mature but needs more testing by the community across platforms.

The respective branches are:

    https://github.com/vsg-dev/VulkanSceneGraph/tree/BuildFlexibility

    https://github.com/vsg-dev/osg2vsg/tree/BuildFlexibility

    https://github.com/vsg-dev/vsgXchange/tree/BuildFlexibility

    https://github.com/vsg-dev/vsgImGui/tree/BuildFlexibility

    https://github.com/vsg-dev/vsgQt/tree/BuildFlexibility

    https://github.com/vsg-dev/vsgExamples/tree/BuildFlexibility

And the vsgFramework project branch that illustrates CMake FetchContent to pull in the above:

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

Users should be able to just use vsgFramework to build all the VSG projects together.  I don't expect users to use vsgFramework other than an example how to use CMake.

I would appreciate members of the community to review and test out these branches. If they look solid then I'll merge with respective masters.

Cheers,

Robert

[Robert Osfield]

Hi All,

I haven't had any feedback on the BuildFlexibilty branches yet. I know VSG is compiling across platforms but this doesn't tell me able the build of all the VSG projects work together across platforms. So I'd really appreciate some more eyeballs reviewing the changes and testing things out.

I'd like to get the BuildFlexibility branches merged this week so we have a clean slate for when I tag the next VSG point version bump to 0.6.0 that I'm planning to do at the end of week. This is all in the effort of moving the VSG closer to 1.0.

Thanks for help,

Robert.

[Tim Moore]

On Tue, Aug 16, 2022 at 12:44 PM Robert Osfield <robert....@gmail.com> wrote:

And the vsgFramework project branch that illustrates CMake FetchContent to pull in the above:

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

Users should be able to just use vsgFramework to build all the VSG projects together.  I don't expect users to use vsgFramework other than an example how to use CMake.

I'm curious about that. It seems that many, if not most, projects that use VSG would want vsgXchange and vsgImGui, and vsgFramework would be an easy way to build and install all of them. Are you thinking of the future when "users" would install everything from packages? vsgFramework would still be convenient for contributors to get everything at once.

Tim

[Robert Osfield]

On Wed, 17 Aug 2022 at 15:05, Tim Moore <timo...@gmail.com> wrote:

Users should be able to just use vsgFramework to build all the VSG projects together.  I don't expect users to use vsgFramework other than an example how to use CMake.

I'm curious about that. It seems that many, if not most, projects that use VSG would want vsgXchange and vsgImGui, and vsgFramework would be an easy way to build and install all of them. Are you thinking of the future when "users" would install everything from packages? vsgFramework would still be convenient for contributors to get everything at once.

I expect users will use a wide range of ways of pulling in the VSG and associated dependencies. In the mix I see approach like vsgFramework illustrates a way of rolling your build of dependencies.

For instance a project might want to use vsgEarth, so would need the GDAL, OSG,, osgEath, VSG, osg2vsg, Assimp, vsgXchange and vsgQt all in one coherent uber project. They might look at vsgFramework as a reference to see how to go about it.

 

[Raymond de Vries]

Hi Robert,

Hope you're getting better soon! Take care and take it easy... But you probably can't ;-)

I have done 2 builds:
1. checked out and built the repositories separately. Those are building the same way as master
2. deleted source, build and install from step 1 to be sure that I have no conflicts
3. checked out and built everything via vsgFramework. That's building and installing fine too. I could also run the installed apps.

This was done on Ubuntu 22.04 on x86_64. It's probably very close to you main platform so this was probably just a double check.

I will try other platforms too but little time...

Cheers, take care!
Raymond

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/955f86c4-22e7-4ae9-b2a1-67c4d834da34n%40googlegroups.com.

[Raymond de Vries]

Hi,

I have done a few more builds and they are all ok, as far as I can see (after the small fix you made this afternoon wrt vsglog).

Ubuntu 20.04 x86
Ubuntu 22.04 raspberry pi (with osg2vsg disabled since I did not build the osg)

Cheers, hth,
Raymond

[Robert Osfield]

Hi All,

Today I merged with the respective masters the BuildFlexibility branches of the various VSG projects, and have changed vsgFramework to utilize CMake FetchContent.  This completes the work on improving the VSG and associated projects ability to be used within larger projects that pull the VSG project in using git submodule or CMake FetchContent.

I still have a few minor items I want to complete for 1.0, but the BuildFlexibility along with the DynamicData work now complete and merged bring us much closer to a release state.

Cheers,

Robert.