New build system

Good news. I think I have found the culprit which caused MSVC requiring the “workaround” search path to be added. More commits coming soon.

[quote=“weitjong”][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]
I think I have fixed this Android build problem on Windows host without MKLINK. For those on Windows host without MKLINK, please try to pull and recreate your build tree again. Thanks for reporting any errors back.

I can’t tell if this is by design or not. I am using cmake_generic and set the build tree to ‘Build’. I go in and run make and it completes. It makes a Bin folder inside the Build folder for the artifacts. Whereas my visual studio builds push binaries to the Bin folder like it used to. I am setting a CMAKE_INSTALL_PREFIX to the bin folder and running make install after a build to copy of the binaries to the old bin folder as an easy solution to move the binaries.

For the Visual Studio build: no it should not happen as you described. Bin output folder should be always created relative to the build tree location regardless of which compiler toolchain or generator being used.
For moving the binaries, you may want to consider to use the URHO3D_PREFIX_PATH environment variable as described here in the updated documentation. urho3d.github.io/documentation/H … ing_Native. Instead of bringing your binaries to the assets. This environment variable brings the assets to the binaries wherever they are in their own build trees.

[quote=“weitjong”]
I think I have fixed this Android build problem on Windows host without MKLINK. For those on Windows host without MKLINK, please try to pull and recreate your build tree again. Thanks for reporting any errors back.[/quote]

:smiley:
Yes, It’s fixed, and I make it, another problem::

F:\dev\Urho3D_master\Android>make -j4
[ 5%] “Built target FreeType”
[ 6%] “Built target JO”
[ 6%] “Built target LZ4”
[ 6%] “Built target PugiXml”
[ 6%] “Built target rapidjson”
[ 19%] “Built target SDL”
[ 19%] “Built target StanHull”
[ 19%] “Built target STB”
[ 24%] “Built target AngelScript”
[ 28%] “Built target Lua”
[ 29%] “Built target lua_interpreter”
[ 29%] “Built target luac”
[ 30%] “Built target toluapp”
[ 30%] “Built target Civetweb”
[ 33%] “Built target kNet”
[ 34%] “Built target Detour”
[ 36%] “Built target Recast”
[ 56%] “Built target Bullet”
[ 62%] “Built target Box2D”
[ 62%] Performing configure step for ‘tolua++’
– The C compiler identification is unknown
– The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:25 (project):
No CMAKE_C_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable “CC” or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.

CMake Error at CMakeLists.txt:25 (project):
No CMAKE_CXX_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable “CXX” or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.

– Configuring incomplete, errors occurred!
See also “F:/dev/Urho3D_master/Android/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeOutput.log”.
See also “F:/dev/Urho3D_master/Android/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeError.log”.
make[2]: *** [Source/Urho3D/tolua+±prefix/src/tolua+±stamp/tolua+±configure] Error 1
make[1]: *** [Source/Urho3D/CMakeFiles/tolua++.dir/all] Error 2
make: *** [all] Error 2

[quote=“cnccsk”][quote=“weitjong”]
I think I have fixed this Android build problem on Windows host without MKLINK. For those on Windows host without MKLINK, please try to pull and recreate your build tree again. Thanks for reporting any errors back.[/quote]

:smiley:
Yes, It’s fixed, and I make it, another problem::

F:\dev\Urho3D_master\Android>make -j4
[ 5%] “Built target FreeType”
[ 6%] “Built target JO”
[ 6%] “Built target LZ4”
[ 6%] “Built target PugiXml”
[ 6%] “Built target rapidjson”
[ 19%] “Built target SDL”
[ 19%] “Built target StanHull”
[ 19%] “Built target STB”
[ 24%] “Built target AngelScript”
[ 28%] “Built target Lua”
[ 29%] “Built target lua_interpreter”
[ 29%] “Built target luac”
[ 30%] “Built target toluapp”
[ 30%] “Built target Civetweb”
[ 33%] “Built target kNet”
[ 34%] “Built target Detour”
[ 36%] “Built target Recast”
[ 56%] “Built target Bullet”
[ 62%] “Built target Box2D”
[ 62%] Performing configure step for ‘tolua++’
– The C compiler identification is unknown
– The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:25 (project):
No CMAKE_C_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable “CC” or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.

CMake Error at CMakeLists.txt:25 (project):
No CMAKE_CXX_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable “CXX” or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.

– Configuring incomplete, errors occurred!
See also “F:/dev/Urho3D_master/Android/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeOutput.log”.
See also “F:/dev/Urho3D_master/Android/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeError.log”.
make[2]: *** [Source/Urho3D/tolua+±prefix/src/tolua+±stamp/tolua+±configure] Error 1
make[1]: *** [Source/Urho3D/CMakeFiles/tolua++.dir/all] Error 2
make: *** [all] Error 2[/quote]
When cross-compiling (such as Android build) on Windows host that requires host tool building (such as Lua/LuaJIT), the host tool target will be built by using host native compiler toolchain. The error you received indicates that CMake cannot find one. Make sure you have also installed MinGW toolchain in your host system and the MinGW toolchain path has been added into the PATH environment variable in your host before attempting this. I have updated my first post in this topic to reflect this.

I cannot tell if by design but URHO3D_PREFIX_PATH is missing from the large table of variables. That was the table I was looking to for solutions.

[quote=“weitjong”]
When cross-compiling (such as Android build) on Windows host that requires host tool building (such as Lua/LuaJIT), the host tool target will be built by using host native compiler toolchain. The error you received indicates that CMake cannot find one. Make sure you have also installed MinGW toolchain in your host system and the MinGW toolchain path has been added into the PATH environment variable in your host before attempting this. I have updated my first post in this topic to reflect this.[/quote]

Hmm, I added MinGW to PATH, it works,

Thanks.

That’s because URHO3D_PREFIX_PATH is an “environment variable”. It is not one of the CMake variables or build options, so it it is not listed in the build option table. This environment variable is dealing with Urho3D runtime, while the build options are for building Urho3D with CMake. As such, it is actually listed here. urho3d.github.io/documentation/H … ommandline

You can also tell CMake to use the Urho3D project root as your native build tree and then forget about all this “moving” assets or binaries business all together. However, be warned that this will clutter your source tree with build tree stuff and sort of beat the purpose of us keep refining the build system.

[quote=“cnccsk”][quote=“weitjong”]
When cross-compiling (such as Android build) on Windows host that requires host tool building (such as Lua/LuaJIT), the host tool target will be built by using host native compiler toolchain. The error you received indicates that CMake cannot find one. Make sure you have also installed MinGW toolchain in your host system and the MinGW toolchain path has been added into the PATH environment variable in your host before attempting this. I have updated my first post in this topic to reflect this.[/quote]

Hmm, I added MinGW to PATH, it works,

Thanks.[/quote]
Glad to hear that.

the new changes break cmake_generic.sh on Linux;

[code]$ ./cmake_generic.sh …/myGame
CMake Error at CMake/Modules/Urho3D-CMake-common.cmake:279 (create_symlink):
Unknown CMake command “create_symlink”.
Call Stack (most recent call first):
CMakeLists.txt:47 (include)

– Configuring incomplete, errors occurred!
See also “/data/urho3d/myGame/CMakeFiles/CMakeOutput.log”.
[/code]

Also, if there are major changes made to the Urho3D-CMake-common.cmake file, can the skeleton CMakeLists.txt on urho3d.github.io/documentation/1 … brary.html be updated if needed so that the skeleton CMakelIsts.txt can still be used?

Thanks.

The new macro create_symlink() is in our Urho3D CMake common module. Please kindly make sure you have got rid of all the old files (CMakeLists.txt and *.cmake) from the old build system. Your error message indicates somehow you still have an old file in the mix. Also Please refer to the updated documentation here urho3d.github.io/documentation/H … brary.html. Note the ‘HEAD’ in the path instead of ‘1.32’!

yeah, that was it. I customized some of the cmake rules in the root folder before updating it with the latest from the repository.

Btw, even though the current structure shouldn’t pose a problem to long time users of Urho3D, but if you really want Urho3D framework adoption to rise quickly, you should consider use cases for the newbies who are just being exposed to this awesome framework. We should learn from other popular frameworks such as Cocos2d-x on how they lower their entry barrier to the new users thus helping the new users to adapt to the framework environment quickly. And after they are becoming more familiar with the framework, they can customize their own build systems according to what they want. We definitely can’t expect all new users to be familiar with cmake rules for them to come up with their own build system right away after discovering Urho3D framework.

Just my 2 cents.

yeah, that was it. I customized some of the cmake rules in the root folder before updating it with the latest from the repository.

Btw, even though the current structure shouldn’t pose a problem to long time users of Urho3D, but if you really want Urho3D framework adoption to rise quickly, you should consider use cases for the newbies who are just being exposed to this awesome framework. We should learn from other popular frameworks such as Cocos2d-x on how they lower their entry barrier to the new users thus helping the new users to adapt to the framework environment quickly. And after they are becoming more familiar with the framework, they can customize their own build systems according to what they want. We definitely can’t expect all new users to be familiar with cmake rules for them to come up with their own build system right away after discovering Urho3D framework.

Just my 2 cents.[/quote]
I have commented on this before. This is not the place to pick up the CMake basic or the Android development basic. Having said that, one of the recent GitHub issue has made me to realize that project structure described in the “Using Urho3D as external library” page can be made simpler to avoid misleading the newbie and the page is updated just now.

And although it has not been documented in that page, we have explained before in the other forum topics that your project can use Urho3D library as external library without the aid of our CMake modules or even without using CMake for that matter. Treat the library as any of the third party libraries you have encountered and wanted to use in your project. Do what you need to do to integrate them. Our modules are just an aid.

after android build, can’t normal run, has crashed, the logcat is below, any one know it? (before change build system is normal)

  • daemon not running. starting it now on port 5037 *
  • daemon started successfully *
    --------- beginning of /dev/log/system
    --------- beginning of /dev/log/main
    W/Urho3D ( 3443): Could not get application preferences directory
    I/Urho3D ( 3443): Created 3 worker threads
    I/Urho3D ( 3443): Added resource path /apk/Data/
    I/Urho3D ( 3443): Added resource path /apk/CoreData/
    I/Urho3D ( 3443): Set screen mode 1920x1080 fullscreen
    I/Urho3D ( 3443): Initialized input
    I/Urho3D ( 3443): Initialized user interface
    I/Urho3D ( 3443): Initialized renderer
    I/Urho3D ( 3443): Set audio mode 44100 Hz stereo interpolated
    I/Urho3D ( 3443): Initialized engine

[quote=“cnccsk”]after android build, can’t normal run, has crashed, the logcat is below, any one know it? (before change build system is normal)

  • daemon not running. starting it now on port 5037 *
  • daemon started successfully *
    --------- beginning of /dev/log/system
    --------- beginning of /dev/log/main
    W/Urho3D ( 3443): Could not get application preferences directory
    I/Urho3D ( 3443): Created 3 worker threads
    I/Urho3D ( 3443): Added resource path /apk/Data/
    I/Urho3D ( 3443): Added resource path /apk/CoreData/
    I/Urho3D ( 3443): Set screen mode 1920x1080 fullscreen
    I/Urho3D ( 3443): Initialized input
    I/Urho3D ( 3443): Initialized user interface
    I/Urho3D ( 3443): Initialized renderer
    I/Urho3D ( 3443): Set audio mode 44100 Hz stereo interpolated
    I/Urho3D ( 3443): Initialized engine[/quote]
    I am not able to reproduce your problem on my Linux host system. I have tested running the NinjaSnowWar in the sample APK successfully in the following setup:

32-bit ARM:
API=19 ABI=armeabi-v7a URHO3D_LIB_TYPE=SHARED AVD=test_19_armeabi-v7a
API=21 ABI=armeabi-v7a URHO3D_LIB_TYPE=SHARED AVD=test_21_armeabi-v7a

32-bit INTEL:
API=21 ABI=x86 URHO3D_LIB_TYPE=SHARED AVD=test_21_x86

64-bit INTEL:
API=21 ABI=x86_64 URHO3D_LIB_TYPE=SHARED AVD=test_21_x86_64

If you are on Windows host, double check the “Android/assets” directory to ensure it contains both the “CoreData” and “Data” subdirs and that they are not empty. Also make sure you have configured your Android build tree to target the correct Android API and Android ABI; then install the APK into the compatible AVD or actual device.

I have heard, in iirc, some people are trying to implement their a different scripting language. I think an amalgamation of each subsystem’s headers into 1 file would be useful for them. Personally, if the files could be generated cleanly, I would like the aesthetics of fewer files in the include folder, and increased readability to be a bonus. Food for thought.

Thanks for your efforts on the build system, weitjong. It has always worked like a dream for me.

I decided to try building out-of-source SDK (completely fresh HEAD checked out today, with mingw-w64)

‘mingw32-make install’
[… builds everything, installs many …]

-- Up-to-date: C:/dev/urho/share/Urho3D/Scripts/cmake_vs2013.bat
-- Installing: C:/dev/urho/include/Urho3D/ThirdParty/SDL
CMake Error at Source/ThirdParty/AngelScript/cmake_install.cmake:31 (FILE):
  file INSTALL destination: C:/dev/urho/include/Urho3D/ThirdParty/AngelScript
  is not a directory.
Call Stack (most recent call first):
  Source/cmake_install.cmake:40 (INCLUDE)
  cmake_install.cmake:64 (INCLUDE)

Makefile:64: recipe for target 'install' failed
mingw32-make: *** [install] Error 1

urho/include/Urho3D/ThirdParty/AngelScript/ does exist as a symlink to the source tree (c:/dev/urho3d/Source/ThirdParty/AngelScript/include/).
Install created other symlinks and regular dirs (like SDL) successfully there…

Could probably hack around this but thought I’d report anyway (maybe tracker is preferred?)
Maybe I missed something, sleep/caffeine?

[quote=“carnalis”]Thanks for your efforts on the build system, weitjong. It has always worked like a dream for me.

I decided to try building out-of-source SDK (completely fresh HEAD checked out today, with mingw-w64)

‘mingw32-make install’
[… builds everything, installs many …]

-- Up-to-date: C:/dev/urho/share/Urho3D/Scripts/cmake_vs2013.bat
-- Installing: C:/dev/urho/include/Urho3D/ThirdParty/SDL
CMake Error at Source/ThirdParty/AngelScript/cmake_install.cmake:31 (FILE):
  file INSTALL destination: C:/dev/urho/include/Urho3D/ThirdParty/AngelScript
  is not a directory.
Call Stack (most recent call first):
  Source/cmake_install.cmake:40 (INCLUDE)
  cmake_install.cmake:64 (INCLUDE)

Makefile:64: recipe for target 'install' failed
mingw32-make: *** [install] Error 1

urho/include/Urho3D/ThirdParty/AngelScript/ does exist as a symlink to the source tree (c:/dev/urho3d/Source/ThirdParty/AngelScript/include/).
Install created other symlinks and regular dirs (like SDL) successfully there…

Could probably hack around this but thought I’d report anyway (maybe tracker is preferred?)
Maybe I missed something, sleep/caffeine?[/quote]
You should not choose the SDK install destination location to be the same as your build tree location. You mention that you find the symlink in the ‘c:/dev/urho/include/Urho3D/’ path. That indicates ‘c:/dev/urho’ is your build tree. So, why would you want to install the SDK there again in the build tree? Our FindUrho3D CMake module has been designed to find Urho3D library from both its build tree directly and from installed SDK. It makes no difference to the module or external project referencing Urho3D library either ways.

Try to correct your build tree to change its CMAKE_INSTALL_PREFIX to point to other location. You can edit the CMakeCache.txt in the build tree to modify this variable directly or invoke ‘cmake -DCMAKE_INSTALL_PREFIX=/other/path/to/install/SDK .’ in the build tree itself (replace the dot with the actual path to your build tree location if your working dir is not the build tree). And then perform the ‘make install’ again.

I think we have discussed this before in the other topic. IMHO, a good practice is to prefer forward declaration over include and to only include what it is needed. Having a few header files that amalgamated other header files would not only slow down the build but would also promote a bad practice, although it looks more tidy and convenient to use.