cmake_mingw with all options creates only libUrho3D.a about urho3d

[weitjong]

This is the case also for other cmake build scripts, not just for cmake_mingw.bat. It is documented in "Libray build" section in "Building Urho3D" page. The constraint is even more relevant on Windows platform.

[Canardian]

This means I have to compile whole Urho always 2 times, unless I have 2 seperate git folders?

[weitjong]

Unfortunately, yes, until someone can find a better way.

[weitjong]

Actually, come to think about it, I do have a new idea now on how to tackle this. Have learnt a new CMake trick lately while I was working on LuaJIT cross-compiling build. I will try the idea soon but no promise.

[Canardian]

I also noticed that the Windows build uses WinMain instead of SDL_Main, maybe this could be also unified, since WinMain needs tons of unnecessary windows include files, which SDL_Main doesn't. You can always specify the -mwindows compiler option in g++ when you don't want the DOS window to appear.

[weitjong]

I have no comment on the program main entry point for Windows platform for now, but I suggest you open a new issue to track it. It is easier for me to close this issue later whether the new idea works or not.

[cadaver]

Whenever there's a choice, I would prefer not to define an entrypoint inside a library for the possible trouble it can cause when it's not wanted, even if using WinMain makes it necessary to include windows.h.

On iOS and Android there is no choice, as actual startup happens in Objective-C or Java code.

[weitjong]

I have tested the idea and I have the POC works. Basically I am configuring CMake to generate a project file that builds the source code two times internally, if the library build option is enabled. The build could use up to two binary directories to store two different set of object files with potentially conflicting compiler flags and defines on each directory. Although it works, I have to increase the complexity of the existing CMakeLists.txt to achieve this. Now I am not convinced it's worth it.

[cadaver]

Btw. in case it would make things easier, I would find it acceptable to always combine the sub-libraries (Core, Math, Graphics etc.) into one huge Urho3D library without any CMake trickery (ie. just list the sources for all of them into one CMake target) and then have the tools and example programs use that library similarly as if they were external projects depending on it. Just like projects like Ogre3D do it. This would reduce testing / maintenance burden as we would be basically testing the "external library build mode" the whole time.

[weitjong]

It has been quite a long while since I last check out Ogre3D. Just have a quick glance on Ogre HEAD again today. If I understand correctly, they always build OgreMain including all the other components, plugins, and even samples as shared library (by default). The tools (like SampleBrowser) are then linked against it. Their export headers are defined all over the places and their build scripts are way more complex than ours. And here I am worrying about adding our script complexity just by a little :)

Regarding combining all sub-libraries into one huge one, I think I have discussed it with you before in our past email conversation. It is relatively easy to define all the source files into one CMakeLists.txt, the real problem is to merge all the individual CMakeLists.text logic into one. As you know some of the build configuration is not straightforward. Take LuaScript library for example, not to mention the CMakeLists.txt logic from other 3rd-party libraries. IMO, they are easier to maintain individually as it is now. Ogre3D does not have this problem because they do not fork 3rd-party libraries and expect the dependent libraries to be already installed in the build/host system.

Having said that, I do like the suggestion to always build the Urho3D shared library first (or static lib, configurable) and then link against it afterward for other targets. Thus solving the problem of needing to compile the objects two times. However, that would mean all the tool and sample apps would need to be changed to depend on just 'Urho3D' library instead of the individual sub-libraries. Are we sure we want that now? I believe we have briefly discussed about this also in the past.

[cadaver]

Ogre's build scripts are a monster and I'm glad we're still far away from that :) They have an optional way to setup all third-party libs into a Dependencies folder, from which the CMake scripts find them.

If we were to do the combining, the third-party libraries should stay like before as separate targets, we'd just define the Urho3D library to depend on all of them that are required with the current build options.

You're right that it would worsen maintenance and modularity. There would be however an upside of allowing all engine classes (even Container / Core) to do eg. error logging, as the strict top-down hierarchy of engine libraries would no longer exist.

The VS solution file listing for Urho3D lib would certainly be long and due to needing to support Express versions we couldn't use solution folders.

Rewriting the tools & examples would not be a problem IMO and they would even work as examples of how to use the "single" library.

A majority of the Engine subfolder CMakeLists are just
file (GLOB CPP_FILES *.cpp)
file (GLOB H_FILES *.h)
but yes, LuaScript and Graphics do contain more complex logic.

As you've made the whole external library feature I believe you must make the final call on this.

[weitjong]

The first cut of the change is available now in 'library-build' topic branch.

[cadaver]

Excellent! Tested briefly and fixed Windows static lib build, did not go to shared lib build yet.

In Visual Studio, after one has built the solution first in release mode, then debug, then release again while tweaking only one or a couple of .cpp files, it will link debug mode .obj's into the release executables from the previous debug build. This is potentially deadly, right now it basically requires a clean or a rebuild.

Possible solution is having a prebuild step for the library which copies .obj files from the build-type dependent source directory just before building the library, instead of the individual engine libraries copying their .obj's to destination when they're done.

[weitjong]

Thanks. I have pushed another patch to fix the wrong macro names in the export header file. See commit log for more detail explanation.

Regarding the issue with build type changes (Debug <-> Release), it does not appear on CMake generator that uses Makefile. The build type change would cause some changes somewhere in Makefile rule or flag file the dependency rule depends on (just a guess). On my linux box this scenario would cause Make to build everything from scratch (regardless of source file modification). So, perhaps the other possible solution is to emulate this behavior.

[cadaver]

Visual Studio is tricky because the .sln / .vcproj files already contain all information for the different builds (generated by CMake), and when the user changes the build type, CMake won't know at all unless it's hacked in somehow.

I'll probably try the prebuild step.

[weitjong]

I believe the library-build branch is ready to be merged. Tested OK on Linux, Mac, Windows.

[cadaver]

Yes, it works just as it should in both static & shared mode. I added one final thing, to deploy Urho3D.dll to Bin directory so that examples are ready to run in shared mode. Should be ready to go.

[weitjong]

Done. Commit: e34e26d