search

vsg-dev / vsgXchange

Utility library for converting data+materials to/from VulkanSceneGraph
MIT License
65 stars 39 forks source link

Changed the order of the include folders #184

Closed appcodegen closed 6 months ago

appcodegen commented 6 months ago

So I am not 100% sure what is going on here (probably not the right way to start a PR description ;))

I am using cmake to generate VS2022 project files, and configured it to have an explicit 'binary' folder (-B ./build/_windows), which makes cmake put the 'configured' Version.h file into (".\build_windows\include\vsgXchange\Version.h"). Now, however, in the Visual Studio's project files (as generated by cmake), the include folders are set in the following order:

  1. X:\vsgXchange\include
  2. X:\vsgXchange\build_windows\include
  3. X:\vsgXchange\src\ktx\libktx

Which means that the 'non-configured' Version.h will be 'found' first.. but the problem is that this file does NONE of the 'optional features' defined, ie it looks like this:

/// optional Features

/ #undef vsgXchange_curl / / #undef vsgXchange_openexr / / #undef vsgXchange_freetype / / #undef vsgXchange_assimp / / #undef vsgXchange_GDAL / / #undef vsgXchange_OSG /

While my 'configured' one looks like this

/// optional Features

define vsgXchange_curl

/ #undef vsgXchange_openexr /

define vsgXchange_freetype

define vsgXchange_assimp

define vsgXchange_GDAL

/ #undef vsgXchange_OSG /

In my opinion the 'configured' #include should be FIRST in the search order, so that the symbols for the optional components are correctly set.

Why this (seems to) compile for everyone else I don't understand, maybe this is due to me (mis)using the -B option for cmake? Probably, if the '-B' option is not specified, the 'configured' include will simply overwrite the 'source' version?

robertosfield commented 6 months ago

There shouldn't be a Version.h in the source include/vsgXchange directory, unless at some point you've copied it there, or did an in source build. If it's not either of these then there is something else going on that we need to get to the bottom of.

Could you try removing your vsgXchange directory and then rebuilding from scratch?

appcodegen commented 6 months ago

Thanks for the reply I'll look at this again next week and report back

appcodegen commented 6 months ago

Yes so this was a self-inflicted problem.

I think I had vsgXchange configured/installed into the local source folder (the 'in-source build' you mentioned above) so it put the Version.h header into the include/vsgXchange directory, then re-configured vsgXchange to use a different install folder without cleaning/clobbering the old installation first.. and since include/vsgXchange/Version.h is actually part of the .gitignore file (though I kind of wonder if that's a really good idea) this stale file didn't show up as an 'untracked' file.

Sorry for the confusion