New build system

We have a new build system in the master branch now. Below summarizes the changes that may impact you:
[ul][li] Shell scripts and batch jobs require external user input to determine the build tree location, similar to cmake-gui. All the scripts or batches now expect a “build-tree path” as the first parameter. e.g. cmake_generic.sh ~/MyBuildTree -D URHO3D_64BIT=1.[/li]
[li] The CMake modules now expect to find the main CMakeLists.txt in the project root directory, instead of in the “Source” directory. So, does the “CMake” subdir which contains the “Modules” and “Toolchains” subdirs.[/li]
[li] Cross-compiling build with Lua or LuaJIT enabled is now made simpler. The Urho3D cross-compiling build tree can be configured, generated, and built in one go, instead of jumping back and forth between cross-compiling build tree and native build tree to build the host tool first. Android build with LuaJIT enabled on a Windows host is also now possible with Android NDK toolchain (for the cross-compiling target) and MinGW toolchain (for the host tool target).[/li]
[li] Enforcing SDK include path. For example: #include <Urho3D/Urho3D.h>, instead of #include “Urho3D.h” like in the past. The actual path to the header files need to be specified. For example: #include <Urho3D/Scene/Scene.h>. See sample apps on how the new include path should look like now.[/li][/ul]
There are other smaller changes that may not impact you directly, among others:
[ul][li] Rename cmake_gcc.sh to cmake_generic.sh. Add cmake_generic.bat which is now the base file for all the batch files. The “generic” here means it lets CMake itself to detect and choose which generator to use.[/li]
[li] On Windows host, URHO3D_MKLINK variable is automatically initialized based on Windows user account capability to use MKLINK command.[/li]
[li] Move the “Android” subdirectory from “Source” directory to project root.[/li]
[li] On Android platform, the SDK installs the library with ANDROID_ABI appended similar to the Android library output path, e.g. ${CMAKE_INSTALL_PREFIX}/libs/x86_64 or ${CMAKE_INSTALL_PREFIX}/libs/armeabi-v7a.[/li]
[li] When cross-compiling on Raspberry Pi platform, rename RPI_TOOL variable to RPI_PREFIX and it now expects the “prefix” to the cross-compiling tools similar to how the MINGW_PREFIX is defined.[/li]
[li] All the cross-compiling build trees now have their CMAKE_INSTALL_PREFIX reset to “/usr/local”. That is, it is not “rooted” as in the old build system.[/li][/ul]
Please check the updated documentation for more detail.
[ul][li] For creating a new project using the library: urho3d.github.io/documentation/H … brary.html[/li]
[li] For installing the library as SDK: urho3d.github.io/documentation/H … ng_Library[/li][/ul]

Thanks for your hard work weitjong. I am not a pro cpp user but have always had reliable working builds since day one of Urho, and feel well taken care of. I tested the builds on my machines and they worked like a charm on both windows and linux. I also feel like major changes to the build system should merit a new release. Keeping stable in line with the current build system is good for new users. This is just my opinion though. Thanks again.

I don’t have any problem with the Linux building but I can’t get my Android code to be compiled. What’s the ideal cpp folder tree structure for Android development from the new build system? The previous Rake scallfolding sets up a fairly straighfoward makefile to include your own cpp files. Do we have to write our own CMakeList.txt to include the source code?

Thanks.

I should actually thank Lasse for trusting me to work on the Urho3D build system since the beginning. Practice makes perfect. The truth is, I was a CMake newbie too back then (I think he didn’t know that! :wink: ) We all learn something from this wonderful project in our own interest areas.

Re. making a new release. I have thought about that too. When I first created this issue soon after the Urho3D v1.32 release, I thought the changes could be merged into the master branch fairly quick and a new release won’t be necessary. Little had I known that it would take about one month elapse time to complete the work, partly due to increase in the changes scope. So, it is valid point to raise. I can understand some of you would want to start a new project with the new build system on a more stable branch. @cadaver, this is your call.

I would also take this opportunity to make a point of my own. We only have a handful of platforms now and yet it has taken me a lot of effort to make sure the build works well on all of them. Having the Travis CI to perform the automatic build tests help, but I couldn’t imagine how it would be like when/if in future Urho supports more platforms than we are today. I think this should not be a one man show. In short, we need some new blood in this area. Now, this is a call for you.

[quote=“Faizol”]I don’t have any problem with the Linux building but I can’t get my Android code to be compiled. What’s the ideal cpp folder tree structure for Android development from the new build system? The previous Rake scallfolding sets up a fairly straighfoward makefile to include your own cpp files. Do we have to write our own CMakeList.txt to include the source code?

Thanks.[/quote]
You should know that for Android build, you should structure your project according to Google specification. See topic378.html.

[quote=“weitjong”][quote=“Faizol”]I don’t have any problem with the Linux building but I can’t get my Android code to be compiled. What’s the ideal cpp folder tree structure for Android development from the new build system? The previous Rake scallfolding sets up a fairly straighfoward makefile to include your own cpp files. Do we have to write our own CMakeList.txt to include the source code?

Thanks.[/quote]
You should know that for Android build, you should structure your project according to Google specification. See topic378.html.[/quote]

Thanks, that was the link that I followed before and managed to get my code compiled. According to Zakk as he quoted your reply,
"Quoting Weitjong:

Notice that “rake scaffolding” simply copies the Urho3DPlayer.cpp and
Urho3DPlayer.h there as placeholders. Normally, you should replace these two
files with your own project source files. But for you case, you can leave them
because that is exactly what you want."

Is this still the same, that Urho3DPlayer.cpp and Urho3DPlayer.h are there as placeholders? I followed the prevous methods from the thread you linked and deleted these two files in several tests (including the Tool directory in some of them) and replaced the files with my sources and headers but Urho3DPlayer.cpp and Urho3DPlayer.h are again copied and compiled instead of my sources when I run makefile.

Any pointers?

Thanks.

Not exactly sure at which step you have done wrong, so it is a little difficult for me to advice you on the corrective action.

The rake scaffolding task still does not support creating a new project suitable for Android build. Perhaps I will fix that one day but for now, you have to complement the missing bits yourself as has been outlined by Zakk in his post. The scaffolding task, as of this writing, still tries to copy the Urho3DPlayer.cpp and Urho3DPlayer.h as the placeholder of source files in the newly created project. For Zakk’s case, it is a little different because he wanted to use scripting language in his Android app. The placeholder source files are exactly what it needs for Zakk’s case. In a more general case, however, once the new project is created then one should delete these two source files and replace them with their own source files. Note that, I am talking about the newly created project here. You should leave the “Tools” sub-project in the Urho3D project as it is in any case.

If this is the first time you build for Android platform, perhaps it would be beneficial that you first try to learn from the basic examples provided by Google. This should help you understand what else are missing in the new project created by the current rake scaffolding task.

Words cannot express how impressed I am with Urho3D as a project :smiley: , watching Urho3D develop and grow is really something awesome.

For this new build system I seem to be having a problem with my build procedure… It terminated with the below (error) log

[ 50%] Generating GIT revision number (tag + last commit SHA-1)
Scanning dependencies of target Urho3D
[ 50%] Building CXX object Source/Urho3D/CMakeFiles/Urho3D.dir/Audio/Audio.cpp.o
bj
In file included from C:/Urho_Master/Source/Urho3D/Container/HashMap.h:25:0,
                 from C:/Urho_Master/Source/Urho3D/Precompiled.h:25,
                 from C:\Urho_Master\Source\Urho3D\Audio\Audio.cpp:23:
C:/Urho_Master/Source/Urho3D/Container/../Container/HashBase.h:25:23: fatal erro
r: ../Urho3D.h: No such file or directory
 #include "../Urho3D.h"
                       ^
compilation terminated.
Source\Urho3D\CMakeFiles\Urho3D.dir\build.make:74: recipe for target 'Source/Urh
o3D/CMakeFiles/Urho3D.dir/Audio/Audio.cpp.obj' failed
mingw32-make[2]: *** [Source/Urho3D/CMakeFiles/Urho3D.dir/Audio/Audio.cpp.obj] E
rror 1
CMakeFiles\Makefile2:957: recipe for target 'Source/Urho3D/CMakeFiles/Urho3D.dir
/all' failed
mingw32-make[1]: *** [Source/Urho3D/CMakeFiles/Urho3D.dir/all] Error 2
Makefile:132: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

I traced and found out that the missing file, which is “Urho3D.h”, was actually in “${BUILD_FOLDER}\Source\Urho3D” but it seems the build procedure doesn’t see it, could I have made mistake in my build setup. I used cmake to configure my build and I’m building with minGw-w64 on Windows Vista 32bit

Interesting that you have this issue also using MinGW compiler on Windows host. I thought only MSVC compiler on Windows host get it. Try changing this line github.com/urho3d/Urho3D/blob/m … s.txt#L132 to read: “if (CMAKE_HOST_WIN32)” and see whether it helps.

I can make own cmake rules to link my source to the newly compiled library so it shouldn’t be a big problem. However a standardized cmake rules will make a huge difference in helping new users setting up their projects.

May I make a suggestion? I’m basing this on the way the previous rake scallfolding handles the files and also looking at how other framework such as cococs2d-x organized their folders and cmake rules.

The previous rake scallfolding generates a skeleton directory with Urho3DPlayer.cpp and Urho3DPlayer.h as placeholders and then we can generate makefiles after that in which any file in that directory will be scanned.

The cmake_generic.sh right now directly prepares the directory from Urho3D SDK folder. Instead of two steps process previously now the build is done faster simply in just one step.

My suggestion, is it posssible to include one placeholder folder directly like “Application” for example into your cmake rules which will be setup together with the generated makefiles to just scan source code in it?

Thanks.

for android:

– Found Urho3D: as CMake target
CMake Error at CMake/Modules/Urho3D-CMake-common.cmake:696 (message):
Could not find SDL_android_main.c source file in the Urho3D build tree or
SDK installation. Please reconfigure and rebuild your Urho3D build tree;
or reinstall the SDK.
Call Stack (most recent call first):
Source/Tools/Urho3DPlayer/CMakeLists.txt:30 (setup_main_executable)

– Configuring incomplete, errors occurred!
See also “F:/dev/Urho3D_master/Android/CMakeFiles/CMakeOutput.log”.

As explained before that I also encountered this build error for MSVC on Windows host. Today I have time to try the MinGW build on Windows host myself and I can confirm that the problem is reproducible. I am testing a fix that works for both MSVC and MinGW on Window host/build system. Expect to get a patch soon in the master branch.

Unfortunately I still get the same error :frowning: . I even tried building with mingw build script and it is still giving me that same error

Unfortunately I still get the same error :frowning: . I even tried building with mingw build script and it is still giving me that same error[/quote]
I believe your problem should be fixed now in the master branch. It was not due to the same root cause as MSVC. I found what could be a CMake bug in which file(TO_NATIVE_PATH) converts to forward slash in MinGW build on Windows host, instead of backward slash. The wrong slash direction has caused all the symlinks failed to be created. BTW, I am assuming you are using MKLINK here.

Having said that, I think your reported problem with MinGW on Windows host is a blessing in disguise, as it also reveals an error in my earlier header search path setup for GCC in general. I have applied a hack/patch to fix it. Unfortunately, the MSVC “workaround” is still needed even after this, which is really annoying.

[quote=“Faizol”]My suggestion, is it posssible to include one placeholder folder directly like “Application” for example into your cmake rules which will be setup together with the generated makefiles to just scan source code in it?
Thanks.[/quote]
Thanks for your suggestion. The scaffolding task is not designed to be a one task to rule them all. To me, its purpose is just to get the project started with a sane structure (sane means as expected by our CMake modules). The user should then replace the placeholders and add more structures that suit their own project need. I want to avoid the same mistake that we had made in the past in our build scripts that they assumed too much on user behalf.

[quote=“cnccsk”]for android:

– Found Urho3D: as CMake target
CMake Error at CMake/Modules/Urho3D-CMake-common.cmake:696 (message):
Could not find SDL_android_main.c source file in the Urho3D build tree or
SDK installation. Please reconfigure and rebuild your Urho3D build tree;
or reinstall the SDK.
Call Stack (most recent call first):
Source/Tools/Urho3DPlayer/CMakeLists.txt:30 (setup_main_executable)

– Configuring incomplete, errors occurred!
See also “F:/dev/Urho3D_master/Android/CMakeFiles/CMakeOutput.log”.[/quote]
I am not able to reproduce your problem with a new clean Android build tree on Linux host. Make sure you have run cmake_clean.bat or cmake_clean.sh if you are reusing an old build tree. If this is not cause of your problem then can you tell us which host system are you using?

EDIT: Sorry. I did not see the “F:/” earlier. So, it was an Android build tree on Windows host then. However, I am also not able to reproduce the problem on my Win7 VM with MKLINK privilege on my Windows user account. I get this in the CMakeCache.txt in my Android build tree.

//Path to SDL_android_main.c
ANDROID_MAIN_C_PATH:FILEPATH=C:/Users/weitjong/SDKs/urho3d/android-Build/include/Urho3D/ThirdParty/SDL/android/SDL_android_main.c

Do you get something similar? If not, can you check in your build tree whether you have this SDL_android_main.c file in this path “include/Urho3D/ThirdParty/SDL/android”. Without the MKLINK, the new buildsystem should also perform a hard file copy of the files to their respective locations. But that logic is the least being tested at the moment. So, I will not surprise if something is wrong there.

[quote=“weitjong”]

I believe your problem should be fixed now in the master branch. It was not due to the same root cause as MSVC. I found what could be a CMake bug in which file(TO_NATIVE_PATH) converts to forward slash in MinGW build on Windows host, instead of backward slash. The wrong slash direction has caused all the symlinks failed to be created. BTW, I am assuming you are using MKLINK here.

Having said that, I think your reported problem with MinGW on Windows host is a blessing in disguise, as it also reveals an error in my earlier header search path setup for GCC in general. I have applied a hack/patch to fix it. Unfortunately, the MSVC “workaround” is still needed even after this, which is really annoying.[/quote]

Would I still need to do the below quoted line:

[quote=“Bluemoon”][quote=“weitjong”]

I believe your problem should be fixed now in the master branch. It was not due to the same root cause as MSVC. I found what could be a CMake bug in which file(TO_NATIVE_PATH) converts to forward slash in MinGW build on Windows host, instead of backward slash. The wrong slash direction has caused all the symlinks failed to be created. BTW, I am assuming you are using MKLINK here.

Having said that, I think your reported problem with MinGW on Windows host is a blessing in disguise, as it also reveals an error in my earlier header search path setup for GCC in general. I have applied a hack/patch to fix it. Unfortunately, the MSVC “workaround” is still needed even after this, which is really annoying.[/quote]

Would I still need to do the below quoted line:

No. Just pull and you should be all good. Finger cross.

I’d like to chime in here to say that I’m not digging the new build system, infact I reverted the merge. With the old system all I had to do was cmake_eclipse.sh and rake (plus a few additional trivial steps for android). With this system I was able to compile but couldn’t rake. I hope it gets easier in the near future as I’m going to need to merge bug fixes.

What do you mean exactly by “able to compile but couldn’t rake”?