Project generator (Latest release: January 20'th 2012)

[liberator]

Hi All,

I wrote this tool for myself and then I figured more people might find it useful so I packaged it separately.
Let me know what you think of it. I hope its useful and saves you some time as it did for me.

Please read the accompanied README.txt before using the tool!!!

About:
------------------------

Intro:
The ProjectGenerator tool is meant for automatically generating the bulk
of the project file content based on directory structure and file analysis.
This reduces maintenance time for module/project files and makes it easy to
generate such files for 3'rd party sources with little effort.

History:
I, Dinand Vanvelzen, created this tool to help me build the Galaxy Unlimited
codebase using CMake without having to manually write all the CMake files for
GU libraries and their dependencies. Later I started doing native Android
development which required Android.mk files which CMake could not provide.
As such the CMakeListGenerator tool was later renamed and its functionality
expanded and enhanced to include support for different generator backends
besides CMake.

Example usefullness:
One of the advantages is being able to dump new code releases of dependencies
into the archive without having to go through the code to check which files got
added/deleted etc. Just re-run the generator and you will have up-to-date
module/project files for the build system you are using.
An additional advantage is the automatic generation of include directory paths
which can be a pain to get right, especially with a lot of modules in a complicated
directory structure. Using this tool you can just move the modules around and their
include paths will be correct again as soon as you re-run the generator.


Features:
------------------------

- Automatically locate and list all header and source file for each module
- Ability to manipulate what is excluded/included using processing instructions
- Automatically generates the include paths for each module's dependencies
- Handles most include/source directory structures
- Special processing for platform specific headers/sources is supported.
- Support for combined processing of multipe source trees
- Generate XML project file with all gathered/generated information.
This can be used as input to other tools in a toolchain.
- Extensive flexibility wrt defining modules for multiple platforms just once
without sacrificing the ability to make platform specific customizations
- Support for legacy module definitions as dictated by the CMakeListGenerator tool
- Support for a special kind of module called a "HeaderIncludeLocation" which allows
you to reference a location where you store headers as if it where a module.
- Support for multiple generator backends:
- CMake
- XML
- Android make


Feedback:
------------------------
You can provide feedback at my forums here:
http://www.vanvelzensoftware.com/phpBB2 ... .php?t=111
Additionally you can post here but I'd prefer feedback on my forums so we don't clutter the Ogre forums to much.



You can find it at:
------------------------

Latest versions at: (latest version available: January 20th 2012)
http://gucef.svn.sourceforge.net/viewvc ... easedBins/

Zipped package at: (latest version available: April 5'th 2011)
http://www.vanvelzensoftware.com/postnu ... load&cid=7

ProjectGenerator is a tool that's part of the GUCEF project which you find on the Ogre forums here:
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=34189


How is it being used today:
------------------------

A sample list of libraries that I'm compiling successfully with the help of my tool as a preprocessing step to running CMake:
- Freetype
- FreeImage
- zlib
- zziplib
- various Ogre libraries
- various MyGUI libraries + tools
- GUCEF libraries + tools
- GUCE libaries + apps
- GU libraries + apps
- OIS
- ParsifalXML
- miniupnpc
- libRocket


Example usage / demo:
------------------------

You can see how I utilize the tool myself by checking out the GUCEF, GUCE and GU archives.
GUCEF SVN archive: https://gucef.svn.sourceforge.net/svnroot/gucef
GUCE SVN archive: https://guce.svn.sourceforge.net/svnroot/guce
GU SVN archive: https://projectgu.svn.sourceforge.net/svnroot/projectgu

I recommend making one folder, let's say "GUALL", in which you checkout the three different archives. giving you:
"<MySVNProjects>\GUALL\GUCEF\<project SVN files>"
"<MySVNProjects>\GUALL\GUCE\<project SVN files>"
"<MySVNProjects>\GUALL\GU\<project SVN files>"

If you structure the archive roots like this then the batch files will not require you to setup any environment variables.

Presuming you did the above, now go to "<MySVNProjects>\GUALL\GU\trunk\projects\CMake\"
There you can run any of the batch files for whatever compiler/IDE you wish to use. I myself always use "RunCMake_Shared_MVC9.bat" to generate files for Microsoft Visual Studio 9
If you followed the described steps above you will see the generator being kicked off by the batch file. It will generate information and combine information for all 3 archives into a single solution which will be placed in "<MySVNProjects>\GUALL\GU\trunk\common\bin\MVC9\"
Under Linux (for example Ubuntu, which is what I use) you could use "RunCMake_Shared_CodeBlocks_Unix_Debug.sh" to generate files for Code::Blocks in Debug mode. The concept is the same as described above for Win32.

Hopefully this will give you a nice demo/idea of what the tool can do and how its used. The simplest demo and least likely to be broken (you are using trunk after all) is to just use the GUCEF archive for the demo and not the other archives. It wont showcase the merging of multiple archives but I'm sure you get the point anyway.

Alternatively you can run the tool to generate Android make files by going to
"<MySVNProjects>\GUALL\GU\trunk\projects\Android\"
And then running "GenerateAndroidMakefiles.bat"

[liberator]

Updated the first post to point to the SVN archive containing the latest binaries.
Changes since the first post:

Code: Select all

History:
------------------------

- 15'th March 2010:
     - Added include dir determination based on a dependency's dependencies.
     - Added the ability to exclude specific files using the exclude list. It can now  
       be used to exclude both sub-dirs and files. Just place each entry on a new line as before.
     - Fixed a bug with last sub-dir string logic, having a trailing \ will no longer cause 
       the last sub-dir string to be determinded as being ""
     - Changed include/source dir processing so that every sub-dir and the project dir itself will
       have all known include/source file types added to the project except for directories excluded
       using the exclude list or directories who have a suffix file and are thus treated as a project 
       defined in a sub-dir.
- 18'th Jan 2010:
     - The exclude list functionality now properly accounts for different EOL
       characters in the exclude text file if the file has multiple entries
     - In addition the exclude list can now be used to exclude specific files not
       just folders
     - Added support for multiple rootDir command line arguments in order to process
       multiple roots. This is a nice feature for combining multiple source trees into
       a single CMake project because it will automatically figure out the include directories
       etc for you.

[scniton]

I'll have to check this out! Thanks.

[liberator]

Let me know what you think of it please. Id appreciate feedback.
Thanks!

For examples on how it's used just check the GUCE or GUCE projects.
They heavily rely on this tool. in the "trunk/projects/CMake" dir of the respective projects you will find batch files to generate all the project files for you. They have a batch file called GenerateCMakeLists.bat which invokes the tool which shows you an example invocation. Basically instead of writing the entire CMakeList.txt you now only have to write what is in the CMakeListSuffix.txt file. The rest is automatically generated and combined with your suffix file to form the final CMakeLists.txt

[liberator]

Just wrapped up a new release. Updated the top post to reflect this.

Changes:

Code: Select all

- 18'th March 2010:
     - Drastically improved support for platform directories. Various platforms are now supported
       and any include/source directory structure can be used as long as the platform dir conforms
       to one of the supported names.

Platform dirs now supported:

Code: Select all

  "mswin" for platform "WIN32"
  "win32" for platform "WIN32"
  "win64" for platform "WIN64"
  "linux" for platform "UNIX"
  "osx" for platform "OSX"
  "android" for platform "ANDROID"
  "iphone" for platform "IPHONEOS"
  "glx" for platform "GLX"
  "gtK" for platform "GTK"
  "symbian" for platform "Symbian"

The next thing on my agenda is to enhance the exclude list functionality to support conditional excludes. The exclude list allows you to exclude directories and/or files from being processed by the generator.

[scniton]

Sorry, I haven't had time to have a close look nor do I currently have any projects suited to test this on. This summer I should have a few .

I noticed the KDE script has QT support, do you have any plans for this?

[liberator]

I haven't looked in detail at the KDE script since this tool was intended to allow me to build my code archives the way I want.
I'm one of those people who wants to have the source code of all the modules I'm using and have them all in the same solution in Visual Studio for ease of debugging.

The question of supporting this or that is really a question of what category does the feature fall into. Support for new platforms is as simple as adding directory names in my platform-directory map and the tool will support it. The reason the CMakeLists.txt thats generated can actually be used to generate a project file is because of the CMakeListsSuffix.txt file I introduced. It houses the most basic information.
to give you an idea here is the CMakeListsSuffix.txt for one of the GUCEF modules named gucefCORE:

Code: Select all

add_library( gucefCORE ${HEADER_FILES} ${SOURCE_FILES} ${PLATFORM_HEADER_FILES} ${PLATFORM_SOURCE_FILES} )
add_dependencies( gucefCORE gucefMT )
target_link_libraries( gucefCORE gucefMT )
set_target_properties( gucefCORE PROPERTIES COMPILE_DEFINITIONS GUCEFCORE_BUILD_MODULE )
GUCEF_config_lib( gucefCORE )

This is what I needed to define for my module and the tool generates the rest. Based on the dependencies mentioned in the suffix file it will work out all the proper include paths and everything. O/S specific files are part of ${PLATFORM_HEADER_FILES} and ${PLATFORM_SOURCE_FILES} which are automatically generated from the directory structure. For example, I have some MS Windows specific files in a "mswin" subdir which will be placed within a platform check in the autogenerated section of the CMakeLists.txt file. This platform section will define ${PLATFORM_HEADER_FILES} and ${PLATFORM_SOURCE_FILES} for me.

It works like a charm for most modules. The only modules that are more problematic are those that have all code stuffed in a single directory that does not belong within the module itself such as test code and platform specific code. Right now the current CMakeGenExcludeList.txt system is used to deal with this problem but I want a bit more control which is why I'll make that system a bit smarter in the next release. One of the main things is that I do NOT want to alter the original source code and directory structure of modules if at all possible (excluding setting options in config headers). That way I can just drop new versions of dependency/third-party code in my archive and run the tool to have up-to-date projects within a moments notice.
I'm trying to avoid having to add specialized support for library X or Y and keep it based on generic logic.

Another thing no other option seemed to offer, except to write this tool, was to have my different archives part of the same solution. I have 3 main projects I spend my hobby hours on,.. GUCEF, GUCE and GU. These are all in different archives but are build on-top of each-other according to different architectural layers. My tool will simply take multiple root directories and work out all the dependencies such that I can have all 3 archives become part of the same CMake generated solution file (.sln). No need to spend hours setting up a new development machine. Just fetch the archive from SVN, run the CMake script (batch files which invoke the generator), compile,.. and your good to go on your new machine and start developing with my system/engine/framework (depending on what you chose to do )

[liberator]

Updated the first post for the latest release

Code: Select all

- 16'th April 2010:
     - Greatly improved the flexibility of providing processing instructions to the generator with the
       addition of the processing instructions XML which can be used if the simple exclude list does 
       not suffice. To use this functionality you will need 2 extra modules which is an xml plugin and the
       actual xml library. See the new "Processing instructions" section in the usage notes.
     - All processing instructions are now gathered as a pre-processing step.
     - Processing instructions now support a simple wildcard for excludes. Only '*' is supported right now.
     - Added compilation timestamp in the log so you can check which version of the generator you are using
     - Added compilation timestamp in the generated CMakeLists.txt so you can check which version of the 
       generator you are using.
     - Added outputting the location of the logfile as comment in the generated CMakeLists.txt because some
       people get confused about the location of the log when specifying multiple root directories.
     - Added the creation of a ${ALL_FILES} variable so that you can now specify modules as follows:
       "add_library( exampleLib ${ALL_FILES} )" in the suffix file. This way you don't need to specify the
       4 possible variables individually.

[liberator]

New release May 6'th 2010, updated top post

Code: Select all

- 6'th May 2010:
     - Improved relative path processing to resolve as much of the up dir segments as possible.
       This greatly reduces the number of include dirs because duplicates can now more accurately be
       detected. The vast number of includes for a top level module was actually preventing a module
       from compiling in MVC9.
     - Added check for scenario where a module has headers in both the same folder as the suffix file
       and in sub dirs. In this scenario the headers in the suffix folder would not be included via an 
       include. Now it will add a relative path back into the same dir to force CMake to add the dir.

[ciaran_d]

Hi,
I tried out the generator on a small project but couldn't get it working under my system
Windows7, x64, Quad-core AMD, CRT installed up to Visual Studio 2008 with .Net3.5

It only did something different when I avoided the commandline option (rootDir) and places the executable and dlls in the root folder of the project. Even then it didn't produce any cmakelist files.
I tried also in a directory structore that avoided spaces but that wasn't successful either.

Here's the log:

[SYSTEM] [LVL NORMAL] Added logger
[SYSTEM] [LVL NORMAL] Added logger
[STANDARD] [LVL NORMAL] This tool was compiled on: May 6 2010 @ 23:48:34
[STANDARD] [LVL NORMAL] Recursively loading all processing instructions for root directory "C:\Users\user.name\Documents\Visual Studio 2008\Projects"
[STANDARD] [LVL NORMAL] Identifying all modules for root directory "C:\Users\user.name\Documents\Visual Studio 2008\Projects"
[STANDARD] [LVL NORMAL] Sorting all modules based on build priority,..
[STANDARD] [LVL BELOW_NORMAL] Performed initial sorting based on number of dependencies
[STANDARD] [LVL NORMAL] Finished determining the correct build order (priority) for all modules, assigning priorities and reordering modules to refect this
[STANDARD] [LVL NORMAL] Finished assigning the correct build order for all modules and sorted them accordingly
[STANDARD] [LVL NORMAL] Wrote log file to: C:\Users\user.name\Documents\Visual Studio 2008\Projects\CMakeListsGenerator_Log.txt

Hope this helps,
Ciaran

PS I tried to comment on your forum, but I had trouble there creating an account

[liberator]

Hi Ciaran,

1) The latest version available is from June 11'th 2010
You can download those binaries from: "trunk\tools\CMakeListGenerator\bin\ReleasedBins\Win32\11June2010"
In the GUCEF archive.

This is the version I use to generate my project files.

2) What sort of problem did you have creating on account on my website's forums? If you are more specific I might be able to fix it. Thanks.

3) From the log posted I'm assuming all your project code (.cpp/.c/.h) is under:
"C:\Users\user.name\Documents\Visual Studio 2008\Projects" ?
Note that the later versions of the tool do NOT create projects anymore purely based on the assumption of which subdirs constitute a project. Instead a "CMakeListsSuffix.txt" MUST be present in the dir that represents your project with the minimal information it requires. Auto-determination of what is a project was not robust enough for most people and writing 4 lines of text in the suffix file was something I considered as an acceptable tradeoff.

An example of a suffix file's content is the gucefPATCHER module's suffix file below:

Code: Select all

add_library( gucefPATCHER ${ALL_FILES} )
add_dependencies( gucefPATCHER gucefCOM gucefCOMCORE gucefCORE gucefMT)
target_link_libraries( gucefPATCHER gucefCOM gucefCOMCORE gucefCORE gucefMT )
set_target_properties( gucefPATCHER PROPERTIES COMPILE_DEFINITIONS GUCEFPATCHER_BUILD_MODULE )
GUCEF_config_lib( gucefPATCHER )

Note that the suffix file is not just appended to a list of files. It is actually parsed by the generator for information such as which modules the module depends on and what the actual project name is. All projects listed in "add_dependencies" will get their include paths worked out automatically.
Note that the last function "GUCEF_config_lib()" is a macro along the lines of OGRE's config_lib function. I based GUCEF's CMake system off of OGRE's system but then proceeded to automate it further using the CMakeListGenerator.

Let me know if this helps, we will take it from there.

[liberator]

Info on the May 23'rd release:

Code: Select all

- 23'rd May 2010:
     - Added serialization of all project information into an XML project file called "Project.xml".
       The idea being that this file can be used to generate other output files then just CMake files.
       The main inspiration was generation of Android makefiles which CMake does not currently support.

Info on the June 11'th release:

Code: Select all

- 11'th June 2010:
     - Added 2 command line parameters to provide more control over the generated CMake files.
       Main reason for adding these is so that the generated files can be added to version control
       without constantly being listed as modified every time the tool is run.
     - Altered header for the generated CMakeLists.txt file a little to remove the obsolete header
       info that was always added as part of every auto-generated file.

The following command line params where added:

Code: Select all

- 'addToolCompileTimeToOutput=<true/false>'
     Determines whether to add the compile date-time of the tool to the header of all the CMake 
     files that are generated. This is particulary usefull when you are suspecting that your CMake
     files are not being generated by the correct version of the generator tool.
     The default is for this feature to be turned off.

- 'writeLogLocationToOutput=<true/false>'
     Determines whether the location of the tool logfile should be added at the end of the 
     generated CMake files. This is mainly usefull for debugging your build scripts.
     The default is for this feature to be turned off.

[ModelTheMasses]

"scniton"
Sorry, I haven't had time to have a close look nor do I currently have any projects suited to test this on. This summer I should have a few .

I noticed the KDE script has QT support, do you have any plans for this? It is to my knowledge that this script has the potential to compromise registries in Windows, especially within outlook. It sounds like the the KDE and scanpst.exe are pretty much hand in hand at this point.

Having QT support makes sense so that we can individually customize our UI if we choose to integrate something like that. I would say that the plans for it are to allow each and every user flexibility especially if we are trying to send an animation to a YouTube downloader. Am I wrong?

[liberator]

@ModelTheMasses:
What do you envision when you say QT support?
The tool can support any library as long as you tell it what to do in cases where full-auto does not work (have test app source etc all in 1 dir for example causing saind code to be included in your module).

--------------------

I should note that I'm finalizing the next iteration on this little dev tool. You could consider it version 2.0 because it will be a major change.

A rough changelist to give you an idea of what I will release soon:
- The tool will be renamed in the next release to 'ProjectGenerator' and support multiple generators
- Added support for Android Makefiles, bringing the supported generators to 3 alongside the CMake and XML generator
- Added ability to choose which generators you want to use, you can have multiple execute in a single invocation of the tool
- Designated the current system of using CMakeListsSuffix.txt files as a legacy system and for a limited time will continues to support it for migration to the new method
- Altered the way modules are defined. The non-legacy recommended way of working is to define a ModuleInfo.xml file in the directory deemed to be the module root. This system comes with a number of abilities not previously available.

So what does this new method of defining modules give me?
- It is not specific to CMake but rather an XML based definition of a module.
- Total control over which settings apply to which platform with extreme flexibility due to the new "define as little or as much as needed/wanted" approach. Basically when you define the desired detail for a module you can add said information to specific platform definitions or make it apply to all platforms. To give you an idea of what a new module file (replacement for CMakeListsSuffix.txt concept) looks like I added the example below:

Code: Select all

<ModuleInfoEntry>
    <Module Name="gucefMT" Type="SharedLibrary" Platform="All">
        <Preprocessor>
            <Define String="GUCEF_MT_BUILD_MODULE" />
        </Preprocessor>
    </Module>
    <Module Platform="mswin">
        <Linker>
            <Dependency Name="Winmm" />
        </Linker>
    </Module>
    <Module Platform="linux">
        <Linker>
            <Dependency Name="pthread" />
        </Linker>
    </Module>
</ModuleInfoEntry>

As you can see above this is rather different from the previous CMakeListsSuffix.txt approach. The tool now collects more information since just appending text from a text file wont work for multiple generators such as the Android generator. The thing that has stayed the same is the minimalist approach to defining modules. You can define more information for a module but you don't have to, its totally optional. The tool will still try to auto-determine as much as possible.
This auto generation has the same feature set for now as the CMakeListGenerator did but I'll add more in the future such as programming language determination etc. This in an effort to be able to support projects which include modules made in different languages which is something CMake has problems with. At my work place we use C++/C#/C++CLI all intermixed in solutions for example which is something CMake can't handle. With my tool and a yet-to-be-designed generator backend I could generate the native projects with CMake and then add-on the C# and C++CLI projects via a different process. The flexibility is endless.
For a backend which has support for multiple platforms itself ('cmake' backend) the above example will generate a CMakeLists.txt file with if() conditions for the different platforms specified. In the case of a backend specific to a certain platform ('androidmake' backend) the information for the specific platform and info which applies to all platforms will be merged to provide a single coherent module definition for the given platform.
Some items which you can specify will overrule the settings (if any exist) for the 'AllPlatforms' platform such as the module name. You could specify your module as being called 'MySuperModule' for all platforms and then add a linux specific overide naming it 'MyExtraSuperModule'. All of this aimed at having to define as little as possible for modules/projects while maintaining total flexibility, mainly aimed at lazy power users
Other items will be merged with the 'AllPlatforms' settings (if any exist) such as dependencies etc. You can see this in the example ModuleInfo.xml above where the module for AllPlatforms has 0 dependencies but for linux we add the pthreads library as a link time dependency.

All this coming up in the next release to a download near you.

[liberator]

I updated the top post to reflect the details of the latest version.

Change history:

Code: Select all

- 5'th April 2011:
     - First version of the ProjectGenerator which supports everything the CMakeListGenerator used to support
       plus a lot more. This version supports the legacy system and is meant to bridge between
       the two tools.
     - Basic template support was added for the CMake generator
     - Complete restructuring of the internal data structures allowing greatly increased flexibility in the way
       modules are defined.
     - This is the first version of ProjectGenerator used to generate all the modules/project files for the GUCEF
       archive itself.
- 26'th Jan 2011:
     - First version under the name of ProjectGenerator. Added Android makefile support to the already
       implemented support for CMake and just a plain XML dump of the gathered information.
     - Note that because of issues with the Linux version the character used to seperate cmd line params
       has been changed from ' to *. Please update your scripts invoking the tool accordingly.
     - This version was never publically announced since only the basic features where operational.

Note that the CMakeListGenerator is now superceded by this tool and considered obsolete

[liberator]

I updated the top post to reflect the details of the latest version.

Change history:

Code: Select all

- 20'th January 2012:
     - Linux only: There was a symbol error in the previous binary release. This is a new build from the new trunk code.
       No new ProjectGenerator specific features were added.
- 6'th September 2011:
     - Added support for module type "CodeIncludeLocation". This had to be implemented to support 
       thirdparty code which was using the same code in multiple modules by simply including the code from multiple
       locations. I would not recommend organizing your code this way, but if you need it its now supported.
     - Fixed a bug in the Android makefile generator which could cause some files to be left out of a module by mistake
       when merging a All platforms definition with an Android one.
     - Fixed the Android makefiles doing an if check on the variable value instead of variable existance.

[Brocan]

Hello liberator!

Following your advices, i'm trying to use your project generator to compile ogre for Android, but i don't know how start...

I've just downloaded ogre trunk and ogre dependencies, my current project structure is:

Android/OgreAndroid/ogre_src
Android/OgreAndroid/ogredeps_src
Android/OgreAndroid/ProjectGenerator
Android/NDK
Android/SDK

I think that i need to generate Android.mk files from the CMakeList.txt already present in ogre using your tool, and after that compiling using the .bat provided by the NDK, right?

So, i'm trying to execute your program, following your instructions i execute:

Code: Select all

ProjectGenerator.exe *generators=androidmake* *rootDir=..\ogre_src*

But it does nothing

What are the steps path i must follow?

Thanks in advance!

[liberator]

The ProjectGenerator can generate one or more of 3 possible outputs.
- an XML dump of all gathered info
- CMakeList.txt files per module (not the overall project solution file, that you have to script yourself)
- Android.mk files

These outputs are generated based on input to the tool in the form of ModuleInfo.xml files.
If such a file is encountered in a directory it is considered a project directory. These content of these files is minimal and the tool will auto generate the additional info (such as all the file paths, include paths etc).

As an example I pasted my ModuleInfo.xml for FreeImage below:

Code: Select all

<ModuleInfoEntry>
    <Module Name="FreeImage" Type="SharedLibrary" Platform="mswin;linux">
        <Preprocessor>
            <Define String="FREEIMAGE_EXPORTS" />
            <Define String="OPJ_EXPORTS" />
            <Define String="OPJ_STATIC" />
            <Define String="ZENO_STATIC" />
            <Define String="HALF_EXPORTS" />
            <Define String="IMATH_EXPORTS" />
            <Define String="ILMIMF_EXPORTS" />
        </Preprocessor>
    </Module>
    <Module Platform="mswin">
        <Preprocessor>
            <Define String="_CRT_SECURE_NO_WARNINGS" />
            <Define String="OPENEXR_DLL" />
        </Preprocessor>
    </Module>
</ModuleInfoEntry>

I have not made one for Ogre but it would be something like:

Code: Select all

<ModuleInfoEntry>
    <Module Name="Ogre" Type="SharedLibrary" Platform="mswin;linux;android">
        <Preprocessor>
            <Define String="WhateverOgreNeeds_EXPORTS" />
        </Preprocessor>
    </Module>
</ModuleInfoEntry>

For platform you can use one of the options listed in README.txt. For fully portable code (or code that has its own macros) you can also use platform "All".

The XML is very flexible in that you can either group info together or split out things for different platforms. They will get auto-magically merged by the tool.
If you need to link to something just add a Linker section.

Code: Select all

    <Module Platform="Android">
        <Linker>
            <Dependency Name="dl" />
            <Dependency Name="log" />
        </Linker>
    </Module>

If you need something build before the other project or simply have its header paths included you add a dependency entry:

Code: Select all

        <Dependencies>
            <Dependency Name="gucefMT" />
        </Dependencies>

Were name is the name of another project.

For an example on the Android side of things look into my GUCEF project and check the trunk/projects/Android folder. It has the scripts for both Linux (.sh) and windows (.bat) to invoke all the tooling.
The params to pass to the tool are documented in the README.txt as you know.

Part of my codebase still uses CMakeListsSuffix.txt files which is a holdover from when the project was CMakeListGenerator. This is however deprecated functionality (it still works). Using ModuleInfo.xml is the way to go moving forward. My OgreMain in my GUCE project still uses CMakeListsSuffix.txt