Building VulkanSceneGraph with premake5

[PowerOfNames]

Hello hello!

Im currently working on building VulkanSceneGraph using premake5 instead of cmake.
Its nearly finished (at least for my current needs) configuring.

But I keep running into an issue inside Viewer.cpp (and if Instrumentation is enabled, also in Instrumentation.h). More precicely, lines that do the following:

static constexpr ... "__LINE__" -> gibing the error "error C2131: expression did not evaluate to a constant".

I found out that most (if not all) compilers do NOT support "__LINE__" in constexpr.

One post suggested to add /Zi as buildoption and remove /ZI. This effectively disabled "Edit and Continue" in debug builds.

Its not working for me and I dont ask you to fix my problem.

However, it would be nice if you can explain how or which option and where you enable/disable something, such that you can actually compile the code.

I've been building VulkanSceneGraph before using cmake and didn't run into this issue. But I dont find the cmake-script lines that would change the building/compilation process.

Additional Info:
Im on Windows 10, Visual Studio 2022 (latest build 17.14.x) and building with C++17

Thanks alot!

[robertosfield]

Is there a reason why cmake isn't good enough for you?

As for suggestion "I found out that most (if not all) compilers do NOT support "LINE" in constexpr." could you provide some further information/links on this.

This is odd because lots of folks are using the VSG with different compilers across numerous platforms without issues. You are the first one to ever suggest there might be an issue here. So something odd is happening on your build, I presume because premake5 is introducing problems for some reason.

Personally, I'd suggest just building and installing the VSG using CMake generated build system and then just use premark5 in your own application.

[PowerOfNames]

There is no "real" reason for not using cmake except that I strongly dislike cmake's workflow/syntax and usage. But thats just a personal preference. Also, when working with multiple people who are not familiar with cmake, myself not being very fond of my cmake skills, its just a HUGE time investment in all the bits and bobs one need to configure until you get the desired build working.
In our case, we investigated alternatives for a rendering backend. We need VSG, vsgXchange, glslang and assimp.

It was honestly faster for me with near to no cmake experience and some premake5 experience to build what was desired, then to try to build the libraries in the correct order using the command line (The cmake UI did not deliver a buildable installation and I gave up on it because of time pressure)... This is ofc a me-problem, which is why this discussion is really just to tell me if there is a hidden cmake configuration that I missed, which changes the debug information format (/z7; /Zi or /ZI in vs2022).

This is the post I found. The error message the author provides is exactly what I got. Also, the solution is working as well (just had to fix some other issues I had):
Issue with LINE in constexpr

VSG is running now, so I got it to work with premake5 after all.

[robertosfield]

CMake really shouldn't be hard to use, it's the standard CMake build system used in graphics, the VSG just bobs around in a sea of graphics related APIs that use CMake. So, I'd recommend being patient and learning it.

Even if you've found a work around and got things build with premake5 it's something you'll need to maintain yourself - your mention of it is the first time I've come across it in 33 years of being a professional programmer.

[PowerOfNames]

I dont know. CMake seems to have grown dynamically over the years. For me its much harder to understand the syntax. I'm more or less a beginner (professionelly) If it works, fine, but I feel that every time you want to built a slightly more complex project with Cmake, you (I) need to spend hours upon hours to figure out which checkboxes to tick until it builds as wanted, because everybody in the industry just assumes that you are a cmake master.. That might be true, after 33year definitely. But for rookies, its just ALOT. Expecially because many people have different approaches on how to use cmake.

I learned a ton about it just looking through VSG, vsgXchange and assimps cmake files, but wasnt able to write my a cmake config for my own project that should build using the mentions libs.
Anyways... its fine. People are different and I will, willingly or not, have to deal with cmake in the future as well :D

Thanks for the answer though!

[AnyOldName3]

It's rare that you need to mess with checkboxes as most projects produce a sensible build by default, so the reason you're spending hours on it is probably that none of the checkboxes are even vaguely related to the problem you're experiencing, so none of them can help fix it. The overwhelming majority of the time, the only thing you need to manually specify with a CMake project is CMAKE_PREFIX_PATH, which tells CMake where you've installed the current project's dependencies.

[AnyOldName3]

I found out that most (if not all) compilers do NOT support "LINE" in constexpr.

That simply can't be true. __LINE__ is dealt with by the preprocessor, and has already been replaced by an integer literal by the time the parts of the compiler that deal with constexpr see it. It's like saying you can't use 17 or 567823 in a constexpr context.

Beyond the theoretical, we know that the major C++17-compatible compilers (GCC, Clang and MSVC) can all compile this code just fine when passed the intended compiler flags.

If you absolutely must replace the build system with premake, you should start by using CMake to configure a build system, and then look at the compiler flags it uses and set the same ones via premake. If you make an MSBuild solution, then in Visual Studio, you can right click the VSG .vcsproj, look at its Properties, go into the C/C++ section, and look at the command line. You'll see something like
All options

/MP /ifcOutput "vsg.dir\RelWithDebInfo\" /GS /W3 /Zc:wchar_t /I"C:\C++Libraries\VulkanSceneGraph\VulkanSceneGraph\include" /I"C:\C++Libraries\VulkanSceneGraph\VulkanSceneGraph\build\include" /Zi /O2 /Ob1 /Fd"C:\C++Libraries\VulkanSceneGraph\VulkanSceneGraph\build\lib\vsgrd.pdb" /Zc:inline /fp:precise /external:W0 /D "_MBCS" /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "CMAKE_INTDIR=\"RelWithDebInfo\"" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD /std:c++17 /Fa"vsg.dir\RelWithDebInfo\" /EHsc /nologo /Fo"vsg.dir\RelWithDebInfo\" /Fp"vsg.dir\RelWithDebInfo\vsgrd.pch" /diagnostics:column 

Additional options

%(AdditionalOptions) /external:I "C:/VulkanSDK/1.4.304.1/include" /external:I "C:/C++Libraries/VulkanSceneGraph/install/include" /external:I "C:/VulkanSDK/1.4.304.1/Include" /bigobj /utf-8

If you use another generator, e.g. Ninja, then passing -DEXPORT_COMPILE_COMMANDS=on when configuring the project will give you a file called compile_commands.json which shows you all the build options.

[PowerOfNames]

Well, I was wondering that too. And in the command line you posted (assuming this is from building VSG) you actually have /Zi instead of /ZI -> I wasnt able to find anything about that (I might have been using the wrong search key-words). It might just be that cmake does this automatically, and for premake5 I needed to set one field manually.

[AnyOldName3]

/Zi is the default for CMake's Debug and RelWithDebInfo configurations. /ZI is a niche flag that inherently can't work with all standard-compliant C++, and has a bunch of documented limitations, so it's pretty obvious that you can't expect things to work if you enable it with other people's code.

[PowerOfNames]

That explains it. In premake5 there is an option "symbols on" which essentialy turns on near to all debug features. So without knowing it, I activated /ZI. Thanks for the info, its fixed now :)

[PowerOfNames]

This can be closed :)