I want to write a 3d rendering system in Lua, but it's proven painfully difficult to install the moongl library (or any OpenGL binding for Lua) using luarocks.
It seems like very few people use Lua based off the lack of information/tutorials on Google, so if anyone could tell me what I'm doing wrong it would be greatly appreciated.
Before, luarocks was telling me that it couldn't find OpenGL and therefore couldn't install moongl, but now it says that LUA_INCDIR and LUA_LIBDIR aren't found. It's telling me what command I need to use to set the path to those things, but I can't do that because I don't even know LUA_INCDIR or LUA_LIBDIR are.
What are LUA_INCDIR and LUA_LIBDIR?
Can anyone please explain what I need to do, or if there's an easier way to do this?
LUA_INCDIR is the include directory for Lua (source code)
LUA_LIBDIR is the compiled library for Lua.
What you'll need to do is download the source code and compile it.
After that, set both of the environment variables LUA_INCDIR & LUA_LIBDIR to the correct locations (src directory and the build directory)
Related
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'm new to C++ because I need to use a package called Buddy. I'm not quite familiar with the compiling and the library things but I'm trying to learn. The thing is that the package is a bit old and all the instructions are based on Linux/g++, while I'm using Win10/VS2017. The installation instructions mention that:
Edit the file 'config' to specify your compiler and install option
Type make to make the binary
Type make install to copy the BDD files to their appropriate directories
Could you please help me with where I should do with the mentioned instructions? Or is it not possible to use this kind of package within VS2017?
Thank you very much for your time and help.
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
how do I correctly implement Lua in a C++ program? I downloaded the Lua source, put the .c files in my src folder and the .h files in my include folder, included lua.h in my program's source code (with extern "C"{} of course) and hit "Build".
That's how all the tutorials tell me to use Lua with a C++ project.
But now I get the error "multiple definition of main" and some Symbols in the Lua code that could not be resolved. I understand what the first error means (conflict because Lua has a main and my program also has one), but how can I solve it?
Or did I understand something completely wrong about implementing Lua in a C++ program?
Check to make sure you didn't include luac.c, lua.c, and the source for any other programs that are included with Lua in with your source code. Lua's source includes a few extra utilities (i.e., luac), and chances are you've just included them in the project and forgotten to remove them, thus resulting in having more than one main.
In short, those are separate programs that you don't add to your project. If you can, just build Lua normally, link to the library, and include the header files as normal.
So, on the point of you misunderstanding how to use Lua, you probably did to some degree. It is entirely possible to just copy Lua's source into your code, though probably not advisable. What you really want to do is pull up the extracted Lua source in a terminal and build it. Then (according to Lua's INSTALL document), you'll want to type make platform, where you'll replace platform with whichever platform you're currently using (i.e., I'd use macosx, you might use linux, refer to the INSTALL for which platforms are supported). After that, it's up to you if you want to install it or not, but you'll just do make install (or sudo make install) to get that done.
After that, either add the appropriate linker flags when compiling to link to Lua (e.g., -llua) or alter your project's settings in your editor of choice to do roughly the same thing. That said, you'll want to refer to the INSTALL document provided with Lua for complete instructions on this.
I'm embedding Lua in my projects other way around, preferred way, IMO: compiled Lua as a static library.
Just comment the two main() blocks in Lua.c an Luac.c, then hit build and run again.
I made this on Lua 5.3.
I'm teaching myself OpenGL and I'm implementing ttf text rendering using FreeType 2. I downloaded the library from
http://gnuwin32.sourceforge.net/packages/freetype.htm
and after a couple of minor issues I got it running properly. The thing that's bothering me is that I have to place a copy of freetype6.dll in the directory with my executable in order for the thing to run. I generally try to avoid a bunch of unnecessary dll files floating around. I'm sort of new to windows programming, but from what I understand most libraries can be built to run fully from a lib rather than requiring a dll at runtime. Looking through the documentation from FT is making my brain melt, so I thought I would ask here to see if there were any devs that have worked with FT before and if so, do they know how to build the library such that no dll is required at runtime.
Thank you in advance for any advice or support.
Check out this link. See the section Optional: Installing FreeType (by compiling it yourself)
Follow the instructions and you'll be good to go.
you can generate static lib by getting source code of it... then you won't need dll...and i think freetype2's source is available...
It is something DLL generic. All your DLLs should be in PATH similarly to LD_LIBRARY_PATH. Also under Windows (unlike Unix) the current directory is always in the PATH. So you just need to set your PATH variable to point to location of this dll.
Now, for Unix... you probably just have this library installed by default like hundreds of other useful libraries that are not present under Windows by default.
So... No unless you link statically you should use DLL somehow. And my suggestion - use dll.