So I decided to try to update part of my toolchain...

Tsaukpaetra

@Groaner said in So I decided to try to update part of my toolchain...:

running Cmake again obliterates all my manual edits to correct include and lib file paths.

I may be here, but would the "proper" fix be to fix the cmake scripts?

Edit: Should have read the rest of the post lol

dkf

@Groaner said in So I decided to try to update part of my toolchain...:

there will probably be some pain in going down that route as well

All routes contain pain. If they did not, you'd be done already and seeking something more challenging.

cvi

Use your own CMake files to build their stuff?

I tend to just bite the bullet and write custom build scripts for third party libs to avoid having to deal with their BS. On the other hand, since I use premake (which is less common than e.g. CMake), I basically have to do that anyway if I want to integrate stuff into my build.

dcon

@cvi said in So I decided to try to update part of my toolchain...:

Use your own CMake files to build their stuff?

I tend to just bite the bullet and write custom build scripts for third party libs to avoid having to deal with their BS. On the other hand, since I use premake (which is less common than e.g. CMake), I basically have to do that anyway if I want to integrate stuff into my build.

And for Windows, I create my own vcxproj files. Usually with a couple .prop files so I can easily configure options when they change (at least 2: one for building the lib, one for using the lib)

cvi

@dcon One of the reasons I've ended up using premake is that it generates quite clean VisualStudio project files. The resulting files are standalone, so you don't need premake after generating them (meaning that you can take the project files and distribute them independently). Premake will also generate a solution file, but it's actually possible to take the project files and insert them into another solution with relatively little hassle.

It also seems to do a relatively good job with keeping paths relative in the generated project files, which is a bonus.

Groaner

@dkf said in So I decided to try to update part of my toolchain...:

All routes contain pain. If they did not, you'd be done already

Indeed.

and seeking something more challenging.

You know me. What gave it away, the desire to maintain my own stack?

Groaner

@cvi said in So I decided to try to update part of my toolchain...:

Use your own CMake files to build their stuff?

I tend to just bite the bullet and write custom build scripts for third party libs to avoid having to deal with their BS. On the other hand, since I use premake (which is less common than e.g. CMake), I basically have to do that anyway if I want to integrate stuff into my build.

In order to do that, I would need to learn Cmake to a higher degree than I do now (which is, basically, nada), and/or be able to understand enough of what's wrong with the existing scripts to know what to fix. It might be less effort just to correct the emitted files with a tool.

Groaner

A pretty simple Powershell script to get 95% of the way there.

Still some hand edits, but it'd be just as much of a pain to implement them here since they're specific to individual project files (in a ~35 project VS solution). Aside from that, I'm more or less done with setting up Ogitor so I don't expect to be jumping back into CMake anytime soon.

Decided to get the HydraX plugin working first, since the SkyX CMake configuration won't proceed because it depends on OIS for some strange reason and can't find my OIS install because certain .cmake scripts don't exist in the folder structure. Additionally, and most conveniently, the HydraX community edition on Github already has a VS solution included.

Getting it functional required some steppin', to discover and fix:

The default shaders for HydraX are HLSL, and won't work with the D3D11+ renderer because it uses the D3D equivalent of fixed-function pipeline, last supported in D3D9 and Ogre 1.9 (I'm using GL rendering in my project to get around this limitation for the time being, though Ogre has an emulation layer called RTSS/HLMS which adds some support for ancient shaders in more recent tech). So, I had to change the default in my HydraX install to GLSL, which led to...
STRICT mode woes! As hinted upthread, the new default behavior in Ogre is not only case-sensitive names, but to throw an exception if you attempt to access or delete a resource that doesn't exist instead of "failing" silently. Annoying, but fixed with a couple if ... resourceExists() blocks. Maybe it's time for a pull request?

Now it's time to get SkyX working.

Gąska

@Groaner said in So I decided to try to update part of my toolchain...:

The default shaders for HydraX are HLSL, and won't work with the D3D11+ renderer because it uses the D3D equivalent of fixed-function pipeline

This sentence doesn't make sense to me. HLSL still seems like the language of choice in DX11 and 12, and AFAIK even in DX9, HLSL and fixed functions didn't mix well, if at all.