-
Notifications
You must be signed in to change notification settings - Fork 58
Building The Library
If you would like to document some files, please go there https://github.com/buildaworldnet/IrrlichtBAW/wiki/Documentation.
Clone IrrlichtBAW with
git clone --recurse-submodules -j8 https://github.com/Devsh-Graphics-Programming/Nabla.git
If you haven't cloned recursively, you can still fix that with
git submodule init
git submodule update
But CMake config script will try to initialize submodules for you as well.
Attention! Sometimes there may occour that there won't be any files in submodules directories.
If so, you have to bring them back by using
git reset --hard
on each submodule's directory required! Furthermore you have to git checkout tags/glew-cmake-2.1.0 in glew directory you can find in 3rdparty/CEGUI/glew because of glew commiting politics. Having done it you can switch to your master/root directory and commit those changes if you want, but it isn't necessary to compile entire library.
Long story short, you NEED git.
- CMake (CMake-gui recommended)
- MSVC or GCC
- Vulkan SDK
- Perl
- NASM
- Python 2.7 or later
IMPORTANT: IrrlichtBaW only supports CUDA interop using the Driver API not the Runtime API.
WARNING: Because CUDA needs its own version the GeForce (Quadro or Tesla) Driver, its often a few minor versions behind your automatically updated Windows driver, the install will fail even if it prompts you to agree to installing an older driver. So basically first remove your driver, then install CUDA SDK
- CUDA Toolkit (https://developer.nvidia.com/cuda-downloads)
CMAKE WARNING: On Windows CMake has trouble finding new packages installed after CMake, so its the perfect time to visit cmake.org and check for a new version installer after installing CUDA SDK.
Note : Because CUDA hijacks your C++ compiler, its best that you don't use the IRR_BUILD_WITH_CUDA CMake option unless necessary, overall it may lead to the library and extensions being compiled with wrong (sub-par) optimization and tuning flags, as well as a lower version of the C++ standard (c++20 is currently on the horizon, IrrlichtBaW wants to move to C++17 for the filesystem stuff, and CUDA 10.1 only supports C++14).
You can also thank NVidia for making the CUDA SDK a whole whopping 2.5 GB on Windows.
- gl.h header for OpenGL (possible to obtain even on headless servers from mesa-libgl-devel)
- An OpenCL SDK (can get rid of it by compiling without the two OpenCL files)
IrrlichtBAW uses or will use the following Boost libraries:
- Bimap
- Context (maybe, and if yes only the fcontext_t variant)
- Interprocess
- Special
- Stacktrace (we already have stack tracing on Linux, might be less work to do it on Win)
The maybe's depend on how xplatform and easy to operate the boost::context is, esp w.r.t. Linux, Windows and Android. We will not use boost::fibers as we need our own complex scheduler.
Make sure you have installed the latest version of Visual Studio and CMake. Within older versions sometimes there may occour that Visual Studio outputs an error associated with compiler heap space. If you don't get any error, just skip the point. It's because having x64 project opened the solution still uses 32 bit compiler exe and cannot allocate more than 4G of memory, therefore irrbaw is unbuildable. Furthermore Visual Studio doesn't provide any option to change that. Because of that you have to manually modify .vcxproj xml and add <PreferredToolArchitecture>x64</PreferredToolArchitecture> to PropertyGroup nodes. Pay attention that cmake generates a standard PropertyGroup node, but it isn't enough, because you need to put it into the target where building type is directly specified. It should look like bellow for example:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
<ConfigurationType>StaticLibrary</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<PlatformToolset>v142</PlatformToolset>
</PropertyGroup>
Current example above shows Release mode, but you should consider Debug as well. Having it done, 64bit cl.exe binary usage will be assured. When u get this problem, don't bother with editing all the .vcxprojs. It will probably only matter while building the engine, so the only thing you have to do is edit that .vcxproj you actually use - Irrlicht.vcxproj for instance and that's it. If you know a way to make cmake generating .vcxprojs already having those changes that will solve the issue, it will be great if you let us know about it:)
Best to use cmake-gui.
Run cmake-gui and, as usually, give cmake root IrrlichtBAW directory and where you want CMake to put project files. And "Configure". When CMake asks you to choose compiler/IDE, make sure to check whether there's a distinct option for 64bit mode and, if this is the case, choose this one.
For single-config IDEs (Code::Blocks) you'll have to manually set CMAKE_BUILD_TYPE to Debug or Release. Release is default.
You also have options BUILD_EXAMPLES and BUILD_TOOLS which do exactly what they say. By "tools" you should currently understand just convert2baw.
For Windows MSVC required, minGW build system maintenance will be delegated to the community.
Same as Windows, except that currently we have no way of setting the correct working directory for executing the examples from within the IDE (for debugging). If you care about this please submit an issue/PR/MR to CMake's gitlab.
We recommend the Codelite IDE as that has a cmake-gui generator and has been tested and works relatively nice.
Visual Studio Code suffers from a number of issues such as configuring the CMake every time you want to build a target and slow build times. Here are the issues:
https://github.com/microsoft/vscode-cmake-tools/issues/771
https://github.com/microsoft/vscode-cmake-tools/issues/772
https://github.com/microsoft/vscode-cmake-tools/issues/773
Clang toolset is unmaintained and untested on Linux.
TBD through MoltenVK
TBD through MoltenVK