SolvedThe Forge how to build on linux
✔️Accepted Answer
what would be a good reason to use cmake?
Well tested framework, handles a lot of things that are having to be handled manually right now and thus are very brittle, among significantly more including the below, etc...
It adds another step to the build process that can fail and it is not supported by most of our target platforms.
What would fail about it? It's the most used C/C++ build system out.
And what target platform does it not support? It has greater compatibility and support than even make itself.
The list of supported platforms of this project is actually extremely tiny of the overall cmake system support. The platforms listed in the readme:
Windows 10
Windows 7 support
Linux
Android Pie
macOS
iOS
XBOX One / XBOX One X
PS4
Are all trivial in cmake, even for cross compilation purposes for all of them short of compiling 'to' macos from another platform (but it can still cross-compile to those as well, just might need a docker image for a quick-setup environment or so, or set it up manually), but all are fully supported first-class build targets for local from all except xbox/ps4/ios which have to be cross-compiled to (because of the target system limitations).
In addition, people would be able to work with this project with any IDE of their choice, not some weird ones like codelite (which I've never heard of before this, that is a very very weird IDE to support in this project when the common linux ones are vi/emacs/KDevelop/IntelliC++), where cmake supports them all, including codelite
It is something that shows that a project is built by a single person. You don't want a whole team to spend time on this.
I'm... not actually sure what this is referencing so don't know how to comment on it... ^.^;
I found this project very recently linked from EnTT, so let's give a try building it, see if this might be useful documentation for others to skip a lot of this work:
Just as someone new to looking at this project but significantly not new to C++ in general for over 25 years (and over 30 years for C) I have no clue how to compile it. There is no Makefile, no ninja definition file, no CMakeList.txt file, there is nothing that is even remotely standard for being able to build this project, not even an INSTALL or COMPILE or so instruction file for how to do so as is standard.
The README.md states to run PRE_BUILD.command, but the only thing that file seems to do is curl down a zip file of art assets (which is something cmake itself should be doing as it sets up the environment, not some weird shell script that is for some reason bound to /bin/bash instead of a standard /bin/sh posix shell link, even though it's not using any bash'ism, so it won't work on systems that don't have bash unless the user edits it). And very weirdly, the executable flag for the PRE_BUILD.command file isn't even set it on it the git repo itself, forcing the user to execute it either via bash directly or calling chmod +x on it, which of course would desync it from the git repository as it is then an edited file.
Further reading of the README.md and I'm having issues finding out how to compile this. It uses no build system that I can see so I can only guess it is something custom but if so then it doesn't seem to be documented in the git repo at all.
So at this point I look in the travis file to see what travis is doing, and this is the most sparse travis file I've ever seen. ^.^
First, the travis file only seems to run on osx, so the supposed linux support seems untested, and even then the osx runner is just executing a python file (python in a C++ project?!). Looking in this python file, it is using very non-standard python naming conventions and emacs is yelling at me because it is failing more lint tests than I've seen in a long time, this file needs a go-over for sure.
Hmm, apparently the .gitignore file contains some lines that belong to the global gitignore listing rather than a project one as well the linter is also telling me, and I quite agree with it, definitely some lines that don't belong.
On the python file though, let's see what it does to figure out how to build this on linux, first let's just try running it after telling it to ignore all the lint failures:
/bin/sh: ./PyBuild.py: Permission deniedOh right, the git project is not setup correctly to set the executable bit...
Oy, downloading the art from the server is sooo slow, only around 25.8m/second (I'm using a fresh container for this as I have no clue what the python file will do and it's way dense with a lot of non-build-related-scaffolding to be able to read it clearly right now) and it should be a lot faster than that...
File "./PyBuild.py", line 154
print "Killed Application. Something went wrong with the app, it was idle for too long."
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Killed Application. Something went wrong with the app, it was idle for too long.")?Wait what? Is this a Python2 file? I don't even have python2 on this system it's such an old python version now!
Blah, grabbing another repo to add in, adding python2 to the container, rebuilding everything (which is mostly waiting on the art file to download again) since the dependencies changed... And done... I'd highly highly recommend not using python2 considering it hasn't had any updates in years and is old enough that it is being actively removed from many repositories now, python3 is the only thing that should be used nowadays (or for the past 10-15 years now really)...
Also, the rm: can't remove 'Art.zip': No such file or directory printing out on stderr is really polluting of the log considering that something printing out there automatically marks this build as failed so I have to override that, you should only delete the file if it already exists (basically add [ -f ./Art.zip ] && or so before the rm).
# ... snip a whole *TON* of stuff ...
The command '/bin/sh -c python2 ./PyBuild.py' returned a non-zero code: 255Well... this is fun... let's start at the top of that output:
/The-Forge
make: *** No targets specified and no makefile found. Stop.
make: *** No targets specified and no makefile found. Stop.Ahh, so Makefiles do exist somewhere! Let's find them:
╰─➤ find . -name Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/BulletCollision/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/BulletDynamics/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/src/LinearMath/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/ppu/tests/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/ppu/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/common/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/spu/tests/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/simdmathlibrary/spu/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/software_cache/cache/include/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/vectormathlibrary/tests/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Extras/vectormathlibrary/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Demos/CellSpuDemo/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.77/Demos/OpenGL/ibmsdk/Makefile
./Common_3/ThirdParty/OpenSource/BulletPhysics/2.82/Extras/CDTestFramework/AntTweakBar/src/Makefile
./Common_3/ThirdParty/OpenSource/SPIRV_Cross/Makefile
./Common_3/ThirdParty/OpenSource/SPIRV_Cross/samples/cpp/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/linux/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/linux/contrib/zlib/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/contrib/gtest/make/Makefile
./Common_3/ThirdParty/OpenSource/assimp/4.1.0/contrib/gtest/scripts/test/Makefile
./Common_3/ThirdParty/OpenSource/lua-5.3.5/src/Makefile
./Common_3/ThirdParty/OpenSource/lua-5.3.5/Makefile
./Common_3/ThirdParty/OpenSource/hlslparser/Makefile
./Common_3/ThirdParty/OpenSource/gainput/Ubuntu/Makefile
./Common_3/ThirdParty/OpenSource/gainput/Ubuntu/lib/MakefileUh, so I'm guessing something here is failing to build, but the make output is not detailing 'what' that is considering No targets specified and no makefile found. I'm not finding anything that looks like a log file either, or even an out-of-source build directory either? Hmm, think it's time to delve more into this python file (why does this file exist in a C++ project...)...
Well I was starting to copy/paste code here while commenting on it but it quickly become obvious that this is a build script in python form that I can't even tell if it does any form of caching or dependency management that isn't manual or anything, and there's stuff here about XML files too? And it looks like it is trying to execute something called codelite-make, never heard of that... Let's search:
ERROR: unsatisfiable constraints:
codelite (missing):
required by: world[codelite]Nope, the repositories don't know what codelite is either as nothing exits with codelite in the name... Is it something you have to download manually? To the Google! Apparently it has to be downloaded from https://github.com/eranif/codelite/archive/13.0.tar.gz so grabbing it, untar'ing it, and Oh Hey codelite is a CMake project! Well this should be easy (oy it uses wxWidgets, haven't seen that in years, and it uses the old gtk2, so old it's not even on my old ubuntu dev system that contains just about every common library on it, interesting...):
/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c: In function 'readChars':
/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c:609:13: error: 'fpos_t' {aka 'union _G_fpos64_t'} has no member named '__pos'
if(location.__pos < 0)
^
/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c:623:21: error: 'fpos_t' {aka 'union _G_fpos64_t'} has no member named '__pos'
sizeToRead = endPos.__pos - location.__pos;
^
/tmp/codelite-13.0/sdk/codelite_indexer/libctags/read.c:623:38: error: 'fpos_t' {aka 'union _G_fpos64_t'} has no member named '__pos'
sizeToRead = endPos.__pos - location.__pos;
^Huh, their code is bad... How do they manage to compile this?? Bah, grabbing an old repo with it and installing it that way (hate mixing repo versions...), and done.
Trying the PyBuild.py script again, the make commands seem to work now, however getting a lot of errors of:
[ERROR ] Could not load build settings configuration object (Version 2.1 / build_settings.xml)
make: *** No targets specified and no makefile found. Stop.A whole lot of those. Let's find them:
╰─➤ find . -name build_settings.xmlUh, so... they don't exist...
The last part of the PyBuild.py output was again:
Failed Builds list:
('VisibilityBuffer.workspace/VisibilityBuffer', 'Debug', 'Ubuntu')
('VisibilityBuffer.workspace/VisibilityBuffer', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/01_Transformation', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/02_Compute', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/03_MultiThread', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/04_ExecuteIndirect', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/05_FontRendering', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/07_Tessellation', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/08_Procedural', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/06_MaterialPlayground', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/09_LightShadowPlayground', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/09a_HybridRaytracing', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/10_PixelProjectedReflections', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/13_UserInterface', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/14_WaveIntrinsics', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/15_Transparency', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/16_Raytracing', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/16a_SphereTracing', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/17_EntityComponentSystem', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/18_Playback', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/19_Blending', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/20_JointAttachment', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/21_PartialBlending', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/22_AdditiveBlending', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/23_BakedPhysics', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/24_MultiThread', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/25_Skinning', 'Debug', 'Ubuntu')
('UbuntuUnitTests.workspace/01_Transformation', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/02_Compute', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/03_MultiThread', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/04_ExecuteIndirect', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/05_FontRendering', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/07_Tessellation', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/08_Procedural', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/06_MaterialPlayground', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/09_LightShadowPlayground', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/09a_HybridRaytracing', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/10_PixelProjectedReflections', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/13_UserInterface', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/14_WaveIntrinsics', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/15_Transparency', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/16_Raytracing', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/16a_SphereTracing', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/17_EntityComponentSystem', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/18_Playback', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/19_Blending', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/20_JointAttachment', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/21_PartialBlending', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/22_AdditiveBlending', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/23_BakedPhysics', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/24_MultiThread', 'Release', 'Ubuntu')
('UbuntuUnitTests.workspace/25_Skinning', 'Release', 'Ubuntu')
The command '/bin/sh -c python2 ./PyBuild.py' returned a non-zero code: 255Still no clue how to load this project into KDevelop (it uses cmake as it's default but also supports make, ninja, and a few others, though it has no clue what to make of this git repo) or into emacs or vim (basically the same support).
So yes, from a linux perspective there is no clue how to use this project. It has no standard build system that is understood by any tool that I've ever seen (and by far cmake is the standard build tool for C++ anymore, whether on linux, mac, windows, etc...).
I have a windows 10 system here as well but I got even less far than on linux, the dependency management here on windows is beyond horrible and this project doesn't use any multiplatform C++ dependency management system like Hunter.sh (or the less portable ones like even conan or vcpkg)....
Really badly need docs on how to build. ^.^
Optimally, building would be as something as simple as:
git clone https://github.com/ConfettiFX/The-Forge.git && cd The-Forge && cmake -H. -Bbuild -DCMAKE_BUILD_TYPE=Release -DWHATEVER_BUILD_ARGS_FOR_THE_FORGE_HERE=Blah -DTHE_FORGE_BUILD_EXAMPLES=True && cmake --build build --config ReleaseOr if using KDevelop or emacs or vi or Visual Studio or IntelliC++ or any other number of a few dozen popular C++ IDE's then I should be able to just git clone https://github.com/ConfettiFX/The-Forge.git then load the The-Forge/CMakeLists.txt file as the project and everything Just Works, this is generally what is expected nowadays (and yes that even works fine in modern Windows Visual Studio's too as I have to use for some work projects). Or they should be able to use this project as a git submodule in their own project and just add_subdirectory("deps/The-Forge") or so and it would 'just work' as a library dependency. No need to make sure that sqlite development libraries are installed systemwide (though can use them instead of acquiring the dependency if they exist of course, though I like repeatable builds so proper dependency management is always preferred) or vulkan development libraries (though want the runtime libraries installed system-wide via GPU drivers to actually be able to 'run' the examples) or whatever else.
But so far I've gotten to this point, which I've wrapped up in a simple Dockerfile:
FROM ubuntu:18.04
WORKDIR "/The-Forge"
RUN apt update && apt upgrade -y && apt install -y \
gcc \
g++ \
git \
build-essential \
cmake \
bash \
curl \
cppcheck \
python2.7 \
codelite \
libsqlite3-dev \
libwxbase3.0-dev
RUN rm -rf /var/cache/apt/*
RUN git clone https://github.com/ConfettiFX/The-Forge.git /The-Forge
RUN bash ./PRE_BUILD.command
RUN python2 ./PyBuild.py
ENTRYPOINT [ "bash", "-c" ]
I can't seem to find any details on the build steps for linux other than an ubuntu codelite projects.