Building VFS static lib about opentesarena

[Ragora]

To build components into static libs, you'd have to make sub CMake projects for them and use ADD_SUBDIRECTORY. That's at least how I did it here:

https://github.com/DraconicEnt/KGE/blob/develop/CMakeLists.txt#L122

So for the "support" component:

https://github.com/DraconicEnt/KGE/blob/develop/components/CMakeLists.txt#L3
https://github.com/DraconicEnt/KGE/blob/develop/components/support/CMakeLists.txt

The project isn't building them as separate libraries. It's just building all the source files together into one project. This isn't helpful if you need to debug libraries individually or write test cases for them in a tests application using something like GTest which is what I do here (unless you want the tests in your main app itself, but that's quite a bit messy for no real good reason).

The OpenAL you're using is standard in CMake, the problem with CMake on Windows is that there is no standardized paths for libraries so CMake scripts on Windows generally have to make use of environment variable hints to automatically find stuff. Otherwise, you pretty much have to specify where to find things manually. This is done pretty easily through the Cmake GUI.

[afritz1]

I guess I'm just encountering some issues because I'm not sure what the best CMake conventions are. The goal is to have the CMakeLists.txt file produce the desired output for both your Linux IDE and my Visual Studio.

In general, what is a good directory to have the include and lib folders for the project in? For example, if I was a newcomer and I cloned the repository to a local folder, should the include and lib folders also be in that same place used with a .gitignore, or should they be in a nearby folder that other projects might refer to? I don't want to put my libraries in the System32 directory for example because those are harder to keep track of.

Is there a way to make the generated project file keep my folder structure as well? Visual Studio just seems to be throwing all the code files into a big list. I glanced at this page but it's not yet clear what I should change in CMakeLists.txt.

[kcat]

To build components into static libs, you'd have to make sub CMake projects for them and use ADD_SUBDIRECTORY.

I haven't had to do that. I've never had a problem using ADD_LIBRARY to build a static library, ADD_EXECUTABLE to build an exe, then specify that library to link with the exe, all in one cmake project.

For OpenAL, the easiest way to get building with it on Windows is to download Creative's core SDK and run the installer. It sets specific registry keys during installation about where it's installed to, and the FindOpenAL.cmake script is actually smart enough to check them to find the appropriate lib and header locations. And even though it's built against a different set of libs, OpenAL Soft is 100% ABI compatible to use with the resulting exe (and will sound better and have more features than the DLLs provided by the SDK).

[Ragora]

@kcat
Using ADD_SUBDIRECTORY is just for logical separation. I prefer to keep things cleaner (keep the CMakeLists.txt code with the actual programming) as just jamming everything into one CMake file will turn into literal hell, hence how in the links I provided the "support" component is a completely independent thing pretty much. Keeping things in one CMake project is how you end up with insanity like in OpenMW's CMakeLists.txt as there is no real benefit to keeping it in one file and as long as the structure you use is sensible, you don't really complicate anything. Sure you can use macros (as OpenMW is doing) but I find it easier to follow this way. All of this is especially true for components that might have component-specific logic.

It is very much necessary to me to help keep things simplified in the long run, especially if you make better use of CMake's project property features than I'm currently doing. Even if it isn't a huge part of the CMake build (especially with macros), it still helps at least a little to separate them off like that. That intermediate directory isn't even necessary, you can do something like invoke add_component macros from there.

As a potentially useful side effect, you can also build the libs individually without really having to explicitly deal with it in the other CMake files.

@afritz1
Sorry, I haven't poked at this issue for a while. As far as I know, there isn't any real way to keep your folder structure intact in the generated project. At least, I haven't bothered to check as I primarily work on Linux anyway with IDE's that don't suffer from this. Plenty of IDE's are intelligent enough to deal with the real folder structure (Code::Blocks, CLion) but MSVS doesn't seem to be among them.

[afritz1]

Well, the behavior I've seen with Visual Studio and CMake is that the files listed in the project are actually references to files in the src folder (which could be somewhere else entirely). So, they're not a "concrete" part of the project itself; they're more like links. Regular VS projects don't seem to behave like this. It still shouldn't have an effect on the folder structure, though. I'll need to look more into it.

I think this would just be a problem when adding new files into specific folders.

Has the "GLOB_RECURSE" in our CMakeLists.txt been capturing *.hpp files, too? I don't know if *.h also gets all .hpp files as well.

This CMake command looks promising. I wonder if we would just do that for each folder? I prefer having the .h files and .cpp files together instead of "header files" and "source files" in separate folders.

[Ragora]

The GLOB_RECURSE will only match the .h files. When I wrote that initially, I saw only .h files laying around in the project. You'll either write another invocation to catch .hpp files, or a mask like .h might work.

You could probably look at this stack overflow: https://stackoverflow.com/questions/7787823/cmake-how-to-get-the-name-of-all-subdirectories-of-a-directory and use the selected answer with the SOURCE_GROUP command and GLOB_RECURSE command.

Actually, just using the existing GLOB_RECURSE invocations and using this to sort through what is the same directory might be better: https://cmake.org/cmake/help/v3.0/command/get_filename_component.html

But that's just me trying to automate it, you could just manually do the calls which is part of why I follow the CMake structure above that I mentioned to kcat.

[afritz1]

I think I am going to keep using my own project file with Visual Studio for now. I struggled quite a bit with the CMake GUI today with things like finding the SDL2 and OpenAL paths (I messed around with some .cmake files), and it's producing some unnecessary projects (ALL_BUILD, ZERO_CHECK), too. I'm going to leave the folder structure issue alone for now.

I'd eventually like the CMakeLists.txt to be edited by someone more experienced with Visual Studio + CMake before I start depending on CMake myself for project generation.

I looked at the OpenJK project and they originally had this same problem but eventually everyone moved to CMake. The Windows users use .bat files to give CMake some parameters I guess. I'll consider something like that in the future.

[pcercuei]

Where are SDL2 and OpenAL installed by default?

[Ragora]

@afritz1: It's not so much an issue with inexperience, it's just Windows architecture with no standard directories for anything (so how can you expect to auto-find anything?). On [Ubuntu] Linux you have /usr/include, /usr/local/include, /usr/lib, /usr/local/lib to install stuff (even stuff built from source can usually auto install to the local directories) so CMake can very easily auto find these things.

As @pcercuei is hinting towards, we can at least add CMake hints for the default paths of stuff, but anyone that decides to install stuff to different places for one reason or another is screwed. Ie: Maybe they don't want to install it to C:\ (where arguably this isn't readily available for Linux distros either, but you can symlink or mount stuff if it became necessary). Technically if any of the libraries are sane, their installers would just create environment variables that point to installation directories, so looking at whether or not the installers for these do so and what the environment variables are is better than assuming default directories.

Even then both of these solutions fail for libraries that don't have installers, so the user has to manually do stuff either way (either add environment variables or tell CMake where to find things), WildMIDI & SDL2 seems like it might be a potential example of this unless there's an installer floating somewhere that I didn't see.

[afritz1]

I've just been keeping those various includes and libraries in a folder local to the solution. So in that directory (a.k.a., the root of the repository), there are also the include, lib64, and lib folders on my computer.

I did use @kcat's link to install OpenAL which goes into C:\Program Files (x86)\OpenAL 1.1 SDK, but it isn't being used by the project, I think. I don't have SDL2 installed either, because I have been pointing to those local folders in the solution.

I got the paths to work in the CMake GUI, but I had to experiment with FindSDL2.cmake, FindWildMidi.cmake, and a new FindOpenAL.cmake file. Locally, I just added include/SDL2, include/WildMIDI, and include/AL to the respective include paths and lib64 and lib to the library paths. I'm wondering if I should do something more standard instead (which @Ragora says doesn't happen?). Anyway, I like having those folders local to the solution because it's easier to keep track of which versions of libraries I'm using then.

[Ragora]

@afritz1 You can install stuff to the Visual Studio Directories directly if you desired, it would just be a pain in the ass to have it merged in with all the other crap and no real way to uninstall it in cases of stuff that doesn't have an installer.

Basically, what I'm trying to say in all of the above is that on Windows you'll likely have to deal with stuff manually unless installers are actually setting environment variables (and not all of them do), assuming they even have an installer.

[afritz1]

This is one of the reasons why I like having local copies of the include and library folders in the solution.

[Ragora]

@afritz1 Then it bloats thing up unnecessarily and if there's multiple things that rely on it (other stuff you develop with on system), then it's multiply that by however many times. It also doesn't help new users coming to build your project (unless you want to bloat up your repo with includes and libraries just to facilitate easier Windows builds).

[afritz1]

The Windows developers on OpenMW don't use local include and library folders then? The FindSDL2.cmake in that project has a slightly different format than this one. Maybe we should use that instead. And maybe I should depend on the SDL2DIR environment variable, too. I'm probably not the one to ask about default library paths.

[Ragora]

@afritz1 No, all of the dependencies are external. There's manual setup all around if one or more of those dependencies don't fall into any of the conditions I mentioned above.

And yea, you should use the environment variables whenever possible but it won't be a particular help in terms of automation if no installers or anything set it anyway. I mean, technically it will speed up setting up projects later that use it, but the first time through will be annoying.

[kcat]

I did use @kcat's link to install OpenAL which goes into C:\Program Files (x86)\OpenAL 1.1 SDK, but it isn't being used by the project, I think.
...
I got the paths to work in the CMake GUI, but I had to experiment with FindSDL2.cmake, FindWildMidi.cmake, and a new FindOpenAL.cmake file.

With the OpenAL SDK installed, the default FindOpenAL.cmake should find it without problems. The SDK installer sets a registry key to where it was installed to, and the FindOpenAL.cmake that comes with cmake will look for that key to find it. Anything that has an SDK installer and a FInd*.cmake script (either with the SDK or by default with cmake) should just work to install, and cmake will find it.

For everything else, one option is to set up your own 'base' location that has include/ and lib/ folders for manually-installed SDKs. Then to manually install an SDK, copy the headers to include (making sure to preserve any sub-directories if there's any), copy the libs to lib, and configure your build environment to set the appropriate *DIR environment variable. Then the Find*.cmake script should just work with it.

[afritz1]

My only relevant environment variable appears to be AMDAPPSDKROOT, which is the path for AMD OpenCL. FindOpenCL.cmake finds OpenCL every time, so that's not a problem.

It looks like C:\Program Files (x86)\OpenAL 1.1 SDK would be acceptable for an OpenAL environment variable path (though the include folder has more headers than OpenAL Soft: alext.h, EFX-Util.h, and xram.h?). The variable name would be OPENALDIR, I presume.

For everything else, one option is to set up your own 'base' location that has include/ and lib/ folders for manually-installed SDKs.

I think I'll do this for SDL2DIR to be where I usually unzip the downloaded package to. What does FindWildMidi.cmake look for in terms of environment variables? Is it WILDMIDI or WILDMIDIDIR?

[Ragora]

The CMake script could be added with a couple of possible hint paths at the least for any locally maintained scripts.

And according to the CMake docs for the built-in FindOpenAL indicates it should indeed be OPENALDIR for the environment variable: https://cmake.org/cmake/help/v3.0/module/FindOpenAL.html

For our FindWildMIDI, looks like it doesn't use environment variables. It can according to the documentation of the find_library used: https://cmake.org/cmake/help/v3.0/command/find_library.html

[kcat]

I think I'll do this for SDL2DIR to be where I usually unzip the downloaded package to. What does FindWildMidi.cmake look for in terms of environment variables? Is it WILDMIDI or WILDMIDIDIR?

Currently our FindWildMidi.cmake script doesn't look for any environment variables. But it would be very easy to modify it so it can. In the find_path and find_library calls, add HINTS $ENV{WILDMIDIDIR}

[afritz1]

Okay. I got my environment variables set, and CMake is able to find them all. I'll update the .cmake files on here shortly.

So why is FindOpenAL.cmake built into CMake then? Why isn't there one in the project?

[kcat]

So why is FindOpenAL.cmake built into CMake then? Why isn't there one in the project?

Likely because it's an often-used library and someone made and submitted one to the cmake devs. We don't have one because it's generally not a good idea to have and maintain our own version of something when the existing one works.