SDK Question Visual Studio Community setup

[Urwumpe]

I would recommend taking a look at CMake there BTW with Visual Studio, it works pretty well.

I have a setup right now that uses CMake, a custom CMake module for locating the Orbiter installation (aided by an environment variable) and vcpkg for handling non-orbiter dependencies. All is self-contained that way and easily portable to other computers.

Which is important since my Orbiter notebook failed fatally last weekend and is barely operational now.

 

[msligo]

Thank you kuddel, I think that was the problem. I changed the OrbiterDir macro to a relative file path (..\..\..) and it fixed that error. Unfortunately a new error arose, in that it couldn't find several "meshres_XX.h" files. After a bit of searching, it looks like the "meshc.exe" program also doesn't like spaces in file names, so I bit the bullet and just removed all the spaces in my folders. I don't suppose you know a way to make "meshc.exe" work using relative file paths instead?

Aside from that, it all seems to be compiling now. Lots of Warnings, but most of them are of the form '=': conversion from 'double' to 'float', possible loss of data, so I can probably leave them for now.

One Warning that worries me a bit is the following:

MSB8012 TargetPath(D:\Files\Applications\Orbiter2016\ProjectApolloDebug\Orbitersdk\samples\DeltaGlider\DGConfigurator\Release\DGConfigurator.dll) does not match the Linker's OutputFile property value (D:\Files\Applications\Orbiter2016\ProjectApolloDebug\Modules\Startup\DGConfigurator.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile). DGConfigurator C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets 1216


Do you know what causes that, and is it a major problem?


Urwampe. Thank you for the suggestion, I'll look into it, although it might be a bit beyond my level. I have a fairly strong understanding of C++ syntax and object oriented programming, but a poor grasp on everything outside of that (compiling, linking, etc.) Every time I see the word "make" (as in "makefiles") I start to get nervous!

 

[Urwumpe]

Every time I see the word "make" (as in "makefiles") I start to get nervous!

I know that feeling, I had to manually fix the automatically generated makefiles of a project for years, because the old autobuild input files had been made for a version that was deprecated 10 years before I joined the project...


Luckily, CMake is a lot cleaner than that now... right now it is just that for producing the core DLL of the project:

cmake_minimum_required (VERSION 3.10)

find_package(OrbiterSDK 16.0 REQUIRED)
find_package(nlohmann_json 3.2.0 REQUIRED)

include_directories("./include")
include_directories("${ORBITERSDK_INCLUDE_DIR}")
link_directories(${ORBITERSDK_LIBRARY})
add_library(SFMVessel MODULE SFMVessel.cpp Interface.cpp)

message("Orbiter libraries are: ${ORBITERSDK_LIBRARIES}")

target_link_libraries(SFMVessel PRIVATE nlohmann_json::nlohmann_json ${ORBITERSDK_LIBRARIES})



install(TARGETS SFMVessel 
    LIBRARY DESTINATION Modules
    ARCHIVE DESTINATION OrbiterSDK/lib
)

Ingredients beyond Visual Studio 2017 Community and Orbiter:
- vcpkg
- And CMake 3.14 (for running vcpkg)

 

[kuddel]

[...]I don't suppose you know a way to make "meshc.exe" work using relative file paths instead?[...]

I know that problem. Unfortunately meshc.exe even fails when you give it "quoted" paths.
Last time I was confronted with this was here.
So replacing the command with the ugly for-construct might be a solution for you, but I think the "current" meshc.exe should work with quoted paths ("meshc /H" for help)[1]


[1] see martins post for commit #78 there, shortly after my request.

 

[Urwumpe]

I know that problem. Unfortunately meshc.exe even fails when you give it "quoted" paths.
Last time I was confronted with this was here.
So replacing the command with the ugly for-construct might be a solution for you, but I think the "current" meshc.exe should work with quoted paths ("meshc /H" for help)[1]


[1] see martins post for commit #78 there, shortly after my request.

I wrote ssumeshc for that....