I've been searching and searching for the method to link OIS with my application. Unfortunately, I've been having issues finding anything. -lois just gives me errors, unfortunately.
Question
I need to know the proper header file for OIS, along with the right lib flag used to link it.
Other info
I'm running Arch Linux, got the package from their repos (with pacman, not yaourt), and haven't been able to link anything. Running locate in bash doesn't really give me much, either.
Update
Found out that the proper way to link OIS is via -lOIS. As far as the proper header file, I have yet to find it.
Edit
Depending on the user's configuration, the proper header file should be either of the following:
OIS.h or OIS/OIS.h.
Also, a good reference:
http://www.ogre3d.org/tikiwiki/Using+OIS
Related
This should be simple, but unfortunately it has given me hours of headache. I have a third party library with multiple DLL files. I want these to be included in the final bazel bin so that I can run my project.
Copying them manually works, but obviously this isn't ideal.
Bazel has docs which use CC_import rule, which seemed to be what I want, except that I need to use linkstatic=0
Using this it tries to build all my packages dynamically into shared object files. This isn't really what I want either , especially since it seems MinGw is failing to link against these.
I'm out of things I can try so any help would be infinitely appreciated. Thanks :)
Hopefully I can save time for someone with this in future, since I finally worked out what my issue was. I think this is an issue with bazel, and so I have raised an issue on their github page.
I was trying to use the cc_import rule but hadn't specified a interface_library. This was having me run into all kinds of issues where it was trying to statically include the DLL. The interface_library is required.
My next issue was I coudln't specfiy a .a file for the interface library, which I believe GCC uses for linking against DLLs. This type isn't supported by bazel. I've raised an issue for this (as above).
My workaround currently is to manually copy the DLLs into the bazel-bin folder. Everything works perfectly if I use a supported file type for the interface_library.
Hope this saves someone time in the future :)
I am looking for a way to get the command invoked to compile a specific file inside CMake as a variable. This is the same "command" as it shows up in a compile_commands.json. It is of the form:
%gcc% %bunch of -DSOMETHINGS% %bunch of -Isome/files% -o %cpp files% ... etc.
The project I am in the process of porting to CMake makes a note of the invoked compiler command inside a file, which I am changing to use the configure_file cmake mechanism. The configured file is needed prior to compiling a specific object.
While searching, I found this answer that is pretty much the same question: cmake - get the used commandline flags "-D". However, it is more than 3 years old, and only concerns retrieving a list of the "-D" flags, which the user solved by manually keeping track. I consider this suboptimal. If this command is written into compile_commands.json, I should be able to access this somehow, right? When exactly is compile_commands.json written? Any change I can get this to write that file for like, a non-functional dummy target or something, then access it and use it to configure my file in the real project?
I know this is kind of against the ethos of CMake, and I love the fact that I don't ever have to manually manage the flags myself, however I find it hard to believe there is no way to get them for a specific file, am I overlooking something?
I have looked at CMake properties on source files, and retrieving them using get_property, however I don't believe I can reconstruct the whole command from these.
I am currently generating Unix makefiles, although the mechanism should optimally also work when generating MSVC project files, which I know CMAKE_EXPORT_COMPILE_COMMANDS does not.
Any thoughts and input on this is greatly appreciated!
My current task is to set up a working environment for an application using (static) Qt and VTK, under Windows 10.
I successfully installed the Qt 5.11.1 static and now want to build VTK. Any version of VTK does, as long as it is compatible to Qt 5.11.1, and the Qt Modules (VTK_Group_Qt) have to be build. For my version, I decided on VTK 8.1.1, but as said, any version would do.
I used the CMake GUI to configure VTK, using MinGW Makefiles (I use a MinGW64), which worked. Then I wanted to proceed generating the Makefile, having turned on VTK_Group_Qt. The paths and version of Qt were already correctly recognized:
Qt5Core_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core
Qt5Gui_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Gui
Qt5Widgets_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Widgets
Qt5_DIR C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5
Made sure that all of those exist. After that, I hit Generate and got the following error:
The imported target "Qt5::Core" references the file
"C:/build_environment/qt-everywhere-src-5.11.1/qtbase/.../qt-everywhere-src-5.11.1/qtbase//mkspecs/win32-g++"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"C:/build_environment/qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core/qt5CoreConfigExtras.cmake"
but not all the files it references
Now, we see that it goes one folder upwards from qtbase and then into the very folder it currently is in, which of course is not a legitimate path. That is, for some reason it tries to go up and then down again, but not with the right amount of folders.
I could try to move the contents of my Qt installation so that the path would be legitimate, but I'd consider that to be pretty much of a smell. Fiddling around in a folder structure that should be correct is not what I understand to be a good solution. I'd rather be willed to change one of the .cmake files of Qt, but that would also be more of a makeshift approach than a real solution as far as I am concerned.
One thing I tried so far was to look at all the CMake variables (checking Advanced in the CMake GUI) in order to see if everything appear to be in order, and especially to see if that faulty path to mkspecs is to be found somewhere there. Found nothing of particular interest.
Does anybody have an idea what went wrong? Tell me if additional information is required. In parallel, I will try to build other versions of VTK, but I'm not too confident that this will solve the issue.
I found a solution which I want to present here, but I consider it a makeshift approach rather than an actual solution, and I hope to see a better answer.
I went to qt-everywhere-src-5.11.1/qtbase/lib/cmake/Qt5Core/ and changed the file Qt5CoreConfigExtrasMkspecDir.cmake (after making a copy).
The original file contains a single line
set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/.../qt-everywhere-src-5.11.1/qtbase//mkspecs/win32-g++")
which leads to the faulty path. I changed it to
set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/mkspecs/win32-g++")
And it now works fine. Still, I don't feel good about having to change a file of Qt, since I consider the answer the question "Is this famous library at fault?" to be "Most likely I used it wrong."
A possible explanation would be that I used the wrong install prefix when configuring Qt, but shouldn't I be allowed to put any valid writeable path in there? Plus, the prefix is still in the cmake file and thus has some validity.
While this is an answer since it fixed the problem, I'd really like to read comments about what could have originally went wrong.
I am working on a project in Code:Blocks, and have successfully added OpenAL to it.
However, I simply cannot find the so called ALUT to this project. I can't find a .lib file anywhere on the internet, but I have found the source code. I am supposed to compile it with CMAKE, but can't find a guide for that. All the tutorials about CMAKE are way too complex for what I want to do. Any solutions?
Looking at another post in the OpenAL feed I saw a recommendation to use freealut. If you're going to use ALUT, I'd use that since it's entirely separate library but is seemingly identical to ALUT.
Recently I obtained a solution which has been created on another person's machine. I have been banging my head into the monitor in the past 2 days trying to fully migrate the solution to my machine. I have been manually changing the directory addresses of the solution and have not been able to compile the solution although I think I have corrected more than 100 paths as of now. Here's my first attempts to migrate the solution to my machine and resolve the issue of not being able to open any of the files.
Now I can open all the files in each project on my machine (after manually changing their paths). However, I am still getting the same errors and I'm not able to compile the project. Below is a picture of the errors I'm getting:
And here's the output log when trying to compile the project. So I wonder, can someone give me some advise on how I should go about doing the whole process automatically? In the output log I see there is a F:\Virtual ... path which indicates the solution been created on a virtual machine. However, I am not using a virtual machine and am not able to find the file file containing that path (F:...) so that I can change it to the correct one (I even do not know what the correct one should be since I am not using a VM).
If you are not able to help me through the description I gave or the output log file, you can download the whole solution from here and then give me some instructions on how I should go about compiling and using it. I really appreciate your help.
Chances are that someone went rogue on the project file, because normally all paths are defined in a way that is relative to the project or solution, making them portable.
In order to fix this, I see two options, either set up the project files from scratch or keep on hacking on them until they compile. Whichever path you take, keep in mind that VS supports placeholders like $(SolutionDir) you can refer to when setting up paths. If that doesn't work, please try to extract a minimal example.
Also, make sure you have a version control system set up, so you can retrace your steps. This should be standard in any software development, but considering the state of the project I wouldn't be surprised to find other, hairy places there.