[MogreBuilder] My mission to build a better Mogre

zarfius

20-01-2012 23:50:53

Introduction
With the recent progress in that people have been making getting various improvements to Mogre it gave me the motivation to help out. My mission is to continue the work on automating the Mogre build process by improving it to be truely automated, customisable and include other plugins such as the Terrain and Paging component.

More importantly, I intend to document each successful step in the process and give back any code changes and binaries. Like many, I don't have a lot of free time but rather than trying to do everything in one sitting I will do a little bit each week and post my progress as soon as I'm finished each iteration.

Multi-part series
To keep everything in one place, provide screenshots and preserve the information forever, I've put my MogreBuilder adventures in detail on my blog. Use the following links to get to each part in the series.

Part 1 - Building Amirabiri's command line version (binaries included)
Part 2 - Getting it into the bitbucket repository, taking a look at McDonte's GUI and testing the samples
Part 3 - Finishing the command line version, fixing the patch issue, running from a config file (new binaries included)
Part 4 - Including Terrain and Paging, Cygon's improvements and automatic version updating (binaries and samples included)

What's next?
I'm taking a break from MogreBuilder development so I can focus my efforts on game development and improvements to Glue Editor. That's not the end though, Beauty has picked up where I left off and is making great progress adding new features and cleaning up the code.

If you would like to help, or have some suggestions take a look at the issues list on the bitbucket repository and/or post your comments in this forum topic.

umityildiz

21-01-2012 09:49:55

You OGRE v1.7.4 is released! Do you prepare in this version?
http://www.ogre3d.org/download/sdk

Tubulii

21-01-2012 10:39:38

You OGRE v1.7.4 is released! Do you prepare in this version?
http://www.ogre3d.org/download/sdk

This topic is only for BUILDING Mogre ;) I think first we need a official 1.7.3 (which you can download it in the forum by the way)

zarfius

21-01-2012 11:06:20

You OGRE v1.7.4 is released! Do you prepare in this version?

To be honest I'm not really sure. My first goal was to build whatever version was easiest and then try building the latest stable version. I'm no expert on how mecurial (hg) works, but I assume that's the part that needs to change to build against different versions of Ogre. Can anyone tell me what version of the Ogre source code this command would grab?

hg clone http://bitbucket.org/sinbad/ogre/ -u v1-7

After a quick look at the Mercurial documentation I think it gets the 'tip' of the v1-7 branch. That probably is OGRE v1.7.4 but I'm not certain. Does anyone know how to confirm this?

Another thing I noticed while looking around is that the Mogre.dll shows a version of 1.7.1 in the Visual Studio properties window. However, I don't think that means anything because the version number is hard coded in the AssemblyInfo.cpp source file. Perhaps we can somehow update that number automatically during the build process too.

[assembly:AssemblyVersionAttribute("1.7.1")];

Tubulii

21-01-2012 18:09:46

All mogre samples runs fine (after recompiling and copying recent MOIS version).
Thank you very much! More or less the same TODO's which I posted some days ago!
I could help you (but I have not much time...)

kojack

21-01-2012 20:56:42

hg clone http://bitbucket.org/sinbad/ogre/ -u v1-7
After a quick look at the Mercurial documentation I think it gets the 'tip' of the v1-7 branch. That probably is OGRE v1.7.4 but I'm not certain. Does anyone know how to confirm this?

That's how I think it should be (I'm still a bit new to mercurial).
v1-7 is a branch name. So cloning it should get the tip of the branch (which would be 1.7.4).
v1-7-4 is a tag. It applies to a specific changeset of the branch.

You can give either to the -u option, but we are actually slightly past 1.7.4 now (two more revisions were checked in after the 1.7.4 tag to fix issues with the build scripts. Using v1-7 should get them correctly).

zarfius

21-01-2012 21:00:00

All mogre samples runs fine (after recompiling and copying recent MOIS version).

Good to know. Where is the source code for the Mogre samples? I can't see them on the main repository.
Perhaps we can provide the option to include MOIS and other addons in the automated build process.

I could help you (but I have not much time...)

You alread have :) Thanks. I don't really have a lot of time either, but any contribution helps.

Tubulii

22-01-2012 13:21:06

Where is the source code for the Mogre samples?
Perhaps we can provide the option to include MOIS and other addons in the automated build process.

I copied the samples of the Mogre sdk into my trunk folder, edited and recompiled them there. I downloaded the MOIS dll from the Wiki (the one of 1.7.1 is compiled with .Net 2).
(very quick and dirty ;) , but it worked as aspected)

MOIS has a separarted repo: https://bitbucket.org/mogre/mogreaddons/overview

zarfius

23-01-2012 01:27:23

I copied the samples of the Mogre sdk into my trunk folder, edited and recompiled them there.

Sorry, I'm still having trouble finding the source code for the samples. Are they supposed to be on bitbucket somewhere? I can see a MogreSamples.sln file but there don't appear to be any projects.

MOIS has a separarted repo: https://bitbucket.org/mogre/mogreaddons/overview

In the next phase of this project I'd like to give the option to include MOIS and samples in the automated build and whatever other plugins I can get working. Ideally, the whole process should be as easy and maintainable as possible.

Tubulii

23-01-2012 18:32:22

Sorry, I'm still having trouble finding the source code for the samples. Are they supposed to be on bitbucket somewhere? I can see a MogreSamples.sln file but there don't appear to be any projects.
Missunderstanding. It is included in the (precompiled) Mogre SDK which you can downloaded by the "common" Mogre user. The sample sourcecode is included but they are not compiled. I do not know where their repo is ... I always used the sample code from the installed MogreSDK... but they should be enough (for testing; they are completly outdated compared to the new sample framework of Ogre >1.7)

zarfius

24-01-2012 04:08:03

It is included in the (precompiled) Mogre SDK which you can downloaded by the "common" Mogre user
Righto. I found them, it's been a while since I've downloaded hte Mogre installer :) I really wasn't expecting the source code to be in the installer and not in the repository.

I do not know where their repo is ...
We should really update the samples and put the source code in the repository. I guess I'll need to get access to the bitbucket repository soon and add my changes, I'll sort the samples out too. I think I need to ask Beauty to get access right?

zarfius

10-02-2012 12:55:25

I've just posted part 3 in the series. The command line version is now automating all of the steps and the build process can be controlled with config file.

I've had a look at including Terrain and Paging tonight, but I'm not really sure how to go about it. I can get Cygon's binaries to work, but I have no idea what he did to create them. What I did notice is that the AutoWrap tool doesn't detect the OgreTerrain.h and related files, but after looking for some time I couldn't figure out why or how to fix it. Any ideas?

Tubulii

12-02-2012 10:28:13

We should really update the samples and put the source code in the repository. I guess I'll need to get access to the bitbucket repository soon and add my changes, I'll sort the samples out too. I think I need to ask Beauty to get access right?
Sorry for my late anser: yes, you need to ask Beauty... (and there must be some kind of repo of the samples, but that is irrelevant, Mogre itself is more important; Samples need to be rewritten anyway (since >1.7), because there is a new ogre sample framework (my opinion))
Maybe we need to ask Cygon, what he did... (-> Last visited: Fri Jan 20, 2012 7:11 pm)

zarfius

13-02-2012 00:20:51

We should really update the samples and put the source code in the repository. I guess I'll need to get access to the bitbucket repository soon and add my changes, I'll sort the samples out too. I think I need to ask Beauty to get access right?
Sorry for my late anser: yes, you need to ask Beauty... (and there must be some kind of repo of the samples, but that is irrelevant, Mogre itself is more important; Samples need to be rewritten anyway (since >1.7), because there is a new ogre sample framework (my opinion))
Maybe we need to ask Cygon, what he did... (-> Last visited: Fri Jan 20, 2012 7:11 pm)


A late answer is better than none ;) Beauty gave me access and I loaded my changes to the MogreBuilder project into the repository. It's working pretty well now.

All of the samples work, so they are better than nothing. Perhaps there is some advantage to rewriting them, but I'm not sure anyone is willing to spare the time. I think getting them into the repository the way they are would be a good start. I was waiting to put them into a separate repositroy, but Beauty hasn't had a chance to get this sorted out yet. Perhaps chucking them into the MogreBuilder repository wouldn't hurt.

I'll ask Cygon and see what happens.

zarfius

13-02-2012 23:53:05

Good news :) I contacted Cygon this week and he got back to me with a detailed reply.

It's been some time since I did those builds, so I don't remember all the details, but I definitely didn't use much automation.

Have you checked the "MogrePatchesAndSolutions-1.7.3.7z" archive from my thread? It contains an 'Instructions.txt' for each project which details exactly what I did (and why, in most cases).

Regarding the Paging and Terrain stuff, I believe to remember adding some of those 'DECLARE_INIT_CLROBJECT_METHOD_OVERRIDE' macros and CLRObject base classes into the related headers by hand after applying the official patch ('ogre_mogre_1.patch' from the Mogre repository, I believe).

After that, AutoWrap happily wired up the terrain and paging classes as well.


I had a look at the Instructions.txt file and it should be possible to use this information to update the MogreBuilder to add Terrain and Paging components.

umityildiz

14-02-2012 20:31:33

I think it would be better corrected.

zarfius

14-02-2012 23:36:35

I think [the Mogre version] would be better corrected.

Yeah, it would be nice to correct this issue. There are a few options I can think of.

1. As quick and dirty hack you could edit the AssemblyInfo.cs file manually. I haven't tried this, but I guess it'd be easy enough.
2. The next simplest approach would be to add another config option. You'd still have to manually change for each new version, but it'd get the job done in one pass.
3. The best method I can think of would be to detect the version of Ogre and make Mogre's version match.

I'll add this to the to-do list for next time. I should be fairly simple to add another automated task to modify the AssemblyInfo.cs file before the build. I'm not sure how to detect the Ogre version yet, but I'll try this approach first. Adding a config option would be the second approach (and perhaps optionally to override the detection or something). Do you have any other thoughts on this?

umityildiz

15-02-2012 08:50:14

Also I wish you success.

zarfius

26-02-2012 05:13:47

Terrain and Paging is now in the MogreBuilder ;)

Zonder

01-03-2012 14:02:04

Nice work!

Good to see a automated process getting in place I did start this my self years ago lost the work due to hard drive dying yeah I didn't backup :S I hadn't got anywhere near this completion though. (I use RAID 5 now to store all code ;))

Are you going to attempt any plug-ins? Thats the only other part that needs auto wrapping I am sure someone did some work on this can't remember who I'll have to check my posts I am sure I would have commented :)

Zonder

01-03-2012 14:06:55

Yeah I did my memory must be going lol

viewtopic.php?f=8&t=10370

Unfortunately he didn't post his code and hasn't been active on here for a year :S

zarfius

02-03-2012 12:13:21

Are you going to attempt any plug-ins?
I'm not sure what I'm going to do yet. My project doesn't really need any plugins at this stage. I don't even need Terrain and Paging to he honest, but I thought it would be an interesting experience to tackle the problem. One of my main goals is to document everything as I go so that others find it easier to continue with it. I've only got limited spare time, so it's not always easy to iron out all the bugs but I'm hoping that it's helping the Mogre community move in the right direction.

umityildiz

02-03-2012 21:51:01

MOIS – include in the build process.
When you add it Will be full!

zarfius

03-03-2012 10:50:56

MOIS – include in the build process.

I had a go at adding MOIS to MogreBuilder tonight. It wasn't particularly difficult but I had to make a small change to the MOIS project in the MogreAddons repository and I don't have access to commit my changes. The screenshot above shows the minimum required steps to build MOIS. However, before it's finished a little more work needs to be done to be able to control exactly what is built each time you run MogreBuilder otherwise it will build Mogre as well which takes a long time.

umityildiz

03-03-2012 18:20:05

I am waiting. :D

Beauty

04-03-2012 20:00:50

the version number is hard coded in the AssemblyInfo.cpp source file. Perhaps we can somehow update that number automatically during the build process too.

[assembly:AssemblyVersionAttribute("1.7.1")];

For my application I wrote some code to grabb the current SVN revision number and embedd it to the 4th position of the Application version number.
(The whole SVN grabbing class I published here. It's a German forum, but my code comments are in English.)

It uses Regular Expressions for the job.
Here is the related code snippet for updating the file AssemblyInfo.cs.
It doesn't work immediately for your need, but you can use my code as base for your own updater.


using System;
using System.Text;
using System.Text.RegularExpressions;
using System.Linq;
using System.IO;


/// <summary>
/// Grabb and save the SVN revision number to the version information of the "AssemblyInfo.cs" file.
/// As result the last number of the application version is equal to the SVN revision. (e.g. "1.0.0.666")
/// </summary>
/// <param name="svnDirectory">Absolute path to the Subversion directory (e.g. "C:\myProject\.svn") </param>
/// <param name="assemblyInfoPath">Absolute path to the file "AssemblyInfo.cs"</param>
public static Boolean UpdateAssemblyInfo(String svnDirectory, String assemblyInfoPath)
{
// get current revision
String revision = SvnTool.GetRevisionNumber(svnDirectory);
if (revision == "")
{
Console.WriteLine("WARNING: Can't update information about Subversion revision."
+ " (Failed to grabb from SVN database)");
return false;
}


//---- update file "AssemblyInfo.cs" ----

try
{
if (File.Exists(assemblyInfoPath) == false)
{
Console.WriteLine("WARNING: Can't update information about Subversion revision. "
+ "(File 'AssemblyInfo.cs' not found)");
return false;
}

Boolean doUpdate = false;

// read file content
FileStream assFileStream = new FileStream(assemblyInfoPath, FileMode.Open, FileAccess.Read);
StreamReader assFileReader = new StreamReader(assFileStream);
Encoding encodingType = assFileReader.CurrentEncoding; // important for saving
String assemblyInfoFileContent = assFileReader.ReadToEnd();
assFileReader.Close();
assFileStream.Close();


//-- update "AssemblyVersion" entry --

// build pattern for [assembly: AssemblyVersion("1.1.0.0")]
String assemblyPattern_1 = @"(\[assembly: AssemblyVersion\(#\d+\.\d+\.\d+\.)\d+(#\)\])";
assemblyPattern_1 = Regex.Replace(assemblyPattern_1, "#", "\""); // replace symbols # by "

// try to find pattern
Match match_1 = Regex.Match(assemblyInfoFileContent, assemblyPattern_1);

if (match_1.Success)
{
String replacement_1 = match_1.Groups[1] + revision + match_1.Groups[2];

// check if content (revision number) changed
if (match_1.Value != replacement_1)
{
// update file content
assemblyInfoFileContent = assemblyInfoFileContent.Replace(match_1.Value, replacement_1);
doUpdate = true;
}
}


//-- update "AssemblyFileVersion" entry --

// build pattern for [assembly: AssemblyFileVersion("1.1.0.0")]
String assemblyPattern_2 = @"(\[assembly: AssemblyFileVersion\(#\d+\.\d+\.\d+\.)\d+(#\)\])";
assemblyPattern_2 = Regex.Replace(assemblyPattern_2, "#", "\""); // replace symbols # by "

// try to find pattern
Match match_2 = Regex.Match(assemblyInfoFileContent, assemblyPattern_2);

if (match_2.Success)
{
String replacement_2 = match_2.Groups[1] + revision + match_2.Groups[2];

// check if content (revision number) changed
if (match_2.Value != replacement_2)
{
// update file content
assemblyInfoFileContent = assemblyInfoFileContent.Replace(match_2.Value, replacement_2);
doUpdate = true;
}
}



// save to file (if needed)
if (doUpdate)
{
FileStream assFileStream2 = new FileStream(assemblyInfoPath, FileMode.Truncate, FileAccess.Write);
StreamWriter assFileWriter = new StreamWriter(assFileStream2, encodingType);
assFileWriter.Close();
assFileStream2.Close();
}

}
catch (IOException e)
{
Console.WriteLine("WARNING: Can't update information about Subversion revision. "
+ "(Problem at access to file 'AssemblyInfo.cs')\n " + e.Message);
return false;
}

return true;

} // UpdateAssemblyInfo()



Well, your Mogre file extension is C++, not C#, the content should be similar.
If you need help, I can do the modification for you.
(For this I need an copy of an AssemblyInfo.cpp file. )


Update
3. The best method I can think of would be to detect the version of Ogre and make Mogre's version match.

I will do the job.
Give me a note where to find the correct version number in the Ogre code, then I will wrote a class to grabb the code and to save it into the AssemblyInfo.cpp file.
I suppose the version number is defined in a header file.
So just give me:
  1. A copy of the Ogre files, which includes the version number.[/*:m]
  2. A copy of the AssemblyInfo.cpp file.[/*:m][/list:u]
    You can send it to me by e-mail: beautyod AT gmx.de

Beauty

04-03-2012 21:24:37

Sorry for my late reply.
Currently I work on my diploma thesis and want to leave my university with a good mark.
And in my free-time I develop electronics for an art project. Its purpose is to control 200 LEDs by a micro controller (using Arduino and 30 shift registers).
This is the reason for my reduced public Mogre activity.
But I'm still in touch with Mogre, because I extend my Mogre based simulation application.


Sorry, I'm still having trouble finding the source code for the samples.

It is included in the (precompiled) Mogre SDK which you can downloaded by the "common" Mogre user. The sample sourcecode is included but they are not compiled. I do not know where their repo is


Here the answer from the topic Add Mogre samples to core code repository?:
Now I found the Mogre-Samples. Currently they are in the MogreSDK repository at directory:
sdk_fs\Samples



We should really update the samples
Updated samples can be checked in to the MogreSDK repository.
If you like, I can give you write-access.

I can get Cygon's binaries to work, but I have no idea what he did to create them.
Cygon created some solution files, which are a good base for compiling.
At least I suppose that this was the reason for his solution file.
(If I remember right, he wrote this in the topic Some x64/x86 builds of Mogre 1.7.3)
Well, I'm not shure, if his solution files are only for compiling modified Mogre sources or also for autowrapping.
Even I still don't know, if he did re-wrap Mogre. Perhaps he just improved the latest autowrapper result.


Samples need to be rewritten anyway (since >1.7), because there is a new ogre sample framework (my opinion)
If I remember right, the Ogre sample framework is a little bit complex. It's purpose is an easy demonstration of Ogre features.
I think for Mogre we don't need a clone of this framework (where each sample is inside of an own dll file).
It's good enough, to have one sample in it's own directory.
The MogreTutorialFramework by amirabiri is a very nice "helper class".
It does Mogre initialisation etc. You just need insert your demo code (and maybe an additionally dll reference).
Sometimes I use it for quick tests. For my own usage I included its source code instead of the dll file. So I know how it works internally and can apply modifications. (e.g. Disable the configuration window, which pops up at each start. How to disable I wrote here.)

The source code of the MogreTutorialFramework you find here.
I think currently it's only in amirabiris private repository.
Perhaps we should add it to one of our official Repositories. (perhaps it still is?)

My suggestion:
Just use the MogreTutorialFramework for each sample and embedd its code there.
The results can replace the current samples code in the SDK repository.

Maybe we need to ask Cygon, what he did...
It seems so that he decided to skip Mogre and used an other 3D solution for his project.
So I suppose he will not spend much time anymore on Mogre.
But maybe he will answer to some questions.
...... Oh, now I read about his answer. It's great that he wrote some documentation. :D



1. As quick and dirty hack you could edit the AssemblyInfo.cs file manually.
Don't miss the "update" of my previous post in this topic.
I will write you a tool class for the version update.


Are you going to attempt any plug-ins? Thats the only other part that needs auto wrapping I am sure someone did some work on this can't remember who I'll have to check my posts I am sure I would have commented :)
Yes, crashes are disturbing and lacks of backups are killing the peace of mind.
It was Marioko, who started to develop a new autowrapper, which also supports wrapping add-ons.
He never finished it and I also don't know huch much of it was ready.
Marioko leaved Mogre, because he has less free time.
Later I wrote him a message and asked for his old Mogre stuff.
He lost all his Mogre data by a harddrive crash, too.
Additionally he has no more interest in Mogre, because he switched to Linux (which isn't supported by Mogre).

Yeah I did my memory must be going lol

viewtopic.php?f=8&t=10370

Unfortunately he didn't post his code and hasn't been active on here for a year :S

Oh, user Spanky also worked on his own autowrapper?
Very interesting. I didn't know until now.

I've only got limited spare time, so it's not always easy to iron out all the bugs but I'm hoping that it's helping the Mogre community move in the right direction.
Your work definitively helps the Mogre community !! :D

Currently we should only concentrate to Mogre and it's "officially" components (terrain and paging).
It's hard enough.

Autowrapping add-ons would be fine, but I suppose it's very complex. Additionally each add-on can cause different problems.
For example look to MHydrax. Even by hand it was a real pain to "just" update it to get work with Mogre 1.7. If people have problems with manual wrapper updates, who hard it would be to develop an autowrapper, which handles such problems?

MOIS – include in the build process.
Oh, maybe I did misunderstood something.
So again:
* Autowrapping for add-ons/plugins --> I disagree
* Building add-ons/plugins --> this is nice

I had a go at adding MOIS to MogreBuilder tonight. [...] I don't have access to commit my changes.
Oh, I thought you have access to all Mogre repositories on BitBucket.
I will check it.

Beauty

04-03-2012 21:37:23

Ok, now Zarifus and McDonte also have write access to the MogreAddons repository.

zarfius

05-03-2012 00:29:11

3. The best method I can think of would be to detect the version of Ogre and make Mogre's version match.
I will do the job.
Give me a note where to find the correct version number in the Ogre code, then I will wrote a class to grabb the code and to save it into the AssemblyInfo.cpp file.
I suppose the version number is defined in a header file.
So just give me:
A copy of the Ogre files, which includes the version number.
A copy of the AssemblyInfo.cpp file.


Thanks for the offer Beauty but I already did this a few days ago :) It's already in the MogreBuilder repository. Sorry I should have mentioned it here, but you can read about it in the comments on my blog.

Beauty

05-03-2012 09:08:04

Don't worry. It's my blame - I was too late.
But it's nice to see that one more point of the TODO list is finished.

Last night I discovered and printed your blog posts.
Today in the train I started to read them.
It's very nice to follow your story of building a better Mogre.

Related to the samples I got an idea.
Don't copy them into the Mogre core repository.
Copy it to the MogreBuilder repository instead. This should be a good place.

Currently it's difficult to test your binaries with my Mogre application, because I need MogreNewt.
If you (or a helper) add support for building MogreNewt, it would be fine. Then I can test it, too.

What's the target of MogreBuilder?
.NET 2.0/3.5 or 4.0 or both.
I read that you offer 4.0 binaries. So I suppose that the builder created it.
But I saw no option for the target .NET version.
Neither in your centralised config file (good idea) nor in the GUI screenshot of McDonte.
So, what are the details?

zarfius

06-03-2012 00:19:26

Last night I discovered and printed your blog posts.
Today in the train I started to read them.
It's very nice to follow your story of building a better Mogre.

It's nice to have someone read them on the train ;)

Related to the samples I got an idea.
Don't copy them into the Mogre core repository.
Copy it to the MogreBuilder repository instead. This should be a good place.

Yes, that seems reasonable. At this stage they will just be a copy of the samples, but I guess the real point is to have an easy way to test the output of the MogreBuilder. Maybe they will evolve to suit that purpose better. I'm not sure how yet.

Currently it's difficult to test your binaries with my Mogre application, because I need MogreNewt.
If you (or a helper) add support for building MogreNewt, it would be fine. Then I can test it, too.

I don't know anything about MogreNewt at this stage. If you know who maintains it or someone who knows how to build it I can take a look. Adding extra tasks into the MogreBuilder is getting easier and having control over what it builds with configuration really helps.

What's the target of MogreBuilder?
.NET 2.0/3.5 or 4.0 or both.
I read that you offer 4.0 binaries. So I suppose that the builder created it.
But I saw no option for the target .NET version.
Neither in your centralised config file (good idea) nor in the GUI screenshot of McDonte.
So, what are the details?

Currently there is no option for the framework target, but it is something I would like to add. I believe it's controlled by either the solution file or project file. Currently they are setup for .NET 4.0 which is why the binaries are coming out that way. I haven't tried but a workaround might be as simple as changing framework target in the project before running the builder.

Beauty

06-03-2012 10:50:40

I don't know anything about MogreNewt at this stage. If you know who maintains it or someone who knows how to build it I can take a look. Adding extra tasks into the MogreBuilder is getting easier and having control over what it builds with configuration really helps.
Newton is a physics and collision detection library, written in C++.
There is no autowrapper. For Ogre and for Mogre the wrappers are written manually. (And the functionality of both wrappers is very similar.)

For wrapping MogreNewt you need the file Newton.dll file, the MogreNewt wrapper code and the Mogre library.
The Newton binaries are in the NewtonSDK. (Perhaps now they can be downloaded seperately.)

Keep in mind: There are different build types for each Newton version. (32/64 bit, normal/high precision, etc.)
When I updated the wrapper to Newton 2 (about 3..4 years ago) I was confused about the different build types.
The Newton developer told me to use the Newton build of this subdirectory:
sdk\x32\dll_vs9
As Cygon posted here, he put the dll files in this path of his binary package:
\References\mogre\net-4.0-x86

I'm not shure, what's the place of the latest MogreNewt version.
The lastest which I found is in on bitbucket.org/mogre/mogreaddons in directory MogreNewt. (It seems so that the code there wasn't touched since February 2011.)
Cygon re-compiled the MogreNewt wrapper, too.
You have all his files. So there you should find everything you need for the first integration steps.
Perhaps some made some improvements.

In the MogreNewt main forum topic I published an appeal to help you. Many MogreNewt users should follow that topic.



In the MogreNewt forum topic I found a one year old proposal.
As I tried to add it to the bug tracker, I recognized, there is no bug tracker in the MogreAddons repository.
Now I created a bug tracker for MogreAddons (and added all projects as component name).
https://bitbucket.org/mogre/mogreaddons/issues

There can be inserted all suggestions and bugs.


Also for the MogreBuilder I created a bug tracker:
https://bitbucket.org/mogre/mogrebuilder/issues

Shall I add some "component names" to make entries more specific?
If you think it's useful, give me some suggestions. (e.g. "GUI")

Beauty

06-03-2012 10:54:38

On the other hand - perhaps it's more useful to collect all bugs/suggestion in the common Mogre bug tracker?
https://bitbucket.org/mogre/mogre/issues

I could add all specific add-on as "component" name for a better overview.

What do you think?
Please tell me your opinion.

zarfius

06-03-2012 22:51:02

On the other hand - perhaps it's more useful to collect all bugs/suggestion in the common Mogre bug tracker?
https://bitbucket.org/mogre/mogre/issues
I could add all specific add-on as "component" name for a better overview.
What do you think?
Please tell me your opinion.

In my opinion you should have a separate bug tracker for each repository otherwise people will get flooded with bugs that they are not interested in. I believe, when you log a bug an email gets sent to the maintainer so they can take a look at it. If they are getting too many emails for bugs in other projects they will start to ignore them.

I'm not shure, what's the place of the latest MogreNewt version.
The lastest which I found is in on bitbucket.org/mogre/mogreaddons in directory MogreNewt. (It seems so that the code there wasn't touched since February 2011.)

On a slightly off-topic issue, perhaps we should make a list of all of the repository locations for each project to make them easier to find and help figure out which are the latest.


Also for the MogreBuilder I created a bug tracker:
https://bitbucket.org/mogre/mogrebuilder/issues
Shall I add some "component names" to make entries more specific?

Good idea. I wouldn't worry too much about component names for MogreBuilder. It's a small enough project that the bug list should be fairly easy to manage anyway.

In the MogreNewt main forum topic I published an appeal to help you. Many MogreNewt users should follow that topic.
Thanks. Since I don't use MogreNewt myself I feel that I will mostly be support for adding tasks to MogreBuilder. So, I need someone who knows how to build MogreNewt already and how it links with the Mogre.dll

Beauty

07-03-2012 00:08:59

In my opinion you should have a separate bug tracker for each repository otherwise people will get flooded with bugs that they are not interested in.
There is no flood of bug reports. Most of them were added by me (when I found a bug report in the forum).
I wonder if it's more confusing to people, when they see 2 or 3 bugtracker links from the Mogre main page.
Well, maybe it doesn't care much, because as seen in the past, there seems to be only low interest for most people. (Or they didn't found bugs? Common feedback to Mogre is rare.)

perhaps we should make a list of all of the repository locations
Somewere in the forums I posted a list of repositories and links. I called it "Mogre structure" or similar.
But today it's late again and I'm to lazy to search for it.
Nethertheless it would be useful to have such a list on a common place.


I need someone who knows how to build MogreNewt already and how it links with the Mogre.dll
I hope there will be somebody.


Did you embedd the Mogre XML commentation tool of smiley80 to the MogreBuilder?
If not - you should put it on your todo list. :wink:
It generates the file Mogre.xml, which is a very good help for Mogre programming.
By this file you see the descriptions of all the Mogre members.
I propose to add this project from smiley80s repository to the MogreBuilder repository.
If you need help, you can tell it in the related forum topic.

zarfius

07-03-2012 00:44:28

Did you embedd the Mogre XML commentation tool of smiley80 to the MogreBuilder?
If not - you should put it on your todo list. :wink:

That's a great idea :)

I wonder if it's more confusing to people, when they see 2 or 3 bugtracker links from the Mogre main page.
Well, maybe it doesn't care much, because as seen in the past, there seems to be only low interest for most people. (Or they didn't found bugs? Common feedback to Mogre is rare.)

As long as the links are clearly marked to show what they are for I think it's fine to have 2 or 3.
Mogre is pretty stable because of the way the autowrapper works. I'm not surprised there are hardly any bug reports. Although, the other problem could be that people don't really know what they need to do when they find a bug. Aside from posting on the forums, I certainly didn't know what to do until now.

CharlesStain

07-03-2012 09:07:03

Sorry for the noob question: All this awesomeness is available in the "official" Mogre releases or at least is its merging planned?
Or we have to download your patched version to experiment with?

Keep going with the excellent work :)

A.

zarfius

07-03-2012 11:43:18

Sorry for the noob question: All this awesomeness is available in the "official" Mogre releases or at least is its merging planned?
Not yet, but it would make sense to use MogreBuilder to build the next offical version of Mogre. In fact, one of my goals is to make sure we can keep Mogre up to date with Ogre on maintenance releases which is why an automated tool is so important.

Or we have to download your patched version to experiment with?
Yes, if you want to play with it now you'll need to download my version. Of course there might be some minor bugs during development but it's stable enough to use.

Who does the official build anyway?

Beauty

07-03-2012 23:17:00

After all the good work of Amirabiri, McDonte and Zarifus I made contribution by creating a wiki page for this project:
http://www.ogre3d.org/tikiwiki/MogreBuilder

If you want to make changes/additions, just do it.

Beauty

07-03-2012 23:49:29

If you like to add an icon, here are some suggestions:

http://www.iconfinder.com/icondetails/2 ... mpile_icon
http://www.iconfinder.com/icondetails/9 ... d_run_icon
http://www.iconfinder.com/icondetails/9 ... e_run_icon
http://www.iconfinder.com/icondetails/8 ... orker_icon
http://www.iconfinder.com/icondetails/3 ... xcode_icon
http://www.iconfinder.com/icondetails/6 ... _tool_icon

zarfius

08-03-2012 00:43:18

After all the good work of Amirabiri, McDonte and Zarifus I made contribution by creating a wiki page for this project
Excellent. I'll be sure to keep the list of blog posts up to date :)

If you like to add an icon, here are some suggestions:
What about something like this for the icon? (this is just a quick draft)

zarfius

08-03-2012 01:31:14

Okay, I've just gone through the forums and tried to gather up all the tasks and put them in one place because there's quite a lot of them now and I was starting to loose track. I figured the easiest place to put them is the MogreBuilder issue tracker because it's easy and available.
https://bitbucket.org/mogre/mogrebuilde ... tatus=open

If you think of any tasks I've missed or want to take on a task that hasn't already been assigned please do :)

Beauty

08-03-2012 01:39:58


Hehe, looks funny!

I've just gone through the forums and tried to gather up all the tasks
Good boy - I got all the e-mails about from the tracker :lol:

Bekas

10-03-2012 07:06:20

Awesome work zarfius!

I also enjoyed reading about your "adventures" in building the tool :)

zarfius

11-03-2012 04:01:21

Awesome work zarfius!
Thanks Bekas. I haven't found the time to finish part 5 in the series yet, but I'm working on it when I can :)

Beauty

11-03-2012 21:21:25

Awesome work zarfius!
Zarifus, this is a compliment from the father of Mogre. :D
Bekas is the person, who created the Mogre way of autowrapping in year ~2007.

umityildiz

11-03-2012 22:35:27

Continue to work. :)
I am waiting for plug-in for audio and physics.
:D

zarfius

11-03-2012 22:50:06

Bekas is the person, who created the Mogre way of autowrapping in year ~2007.
He certainly is a bit of a legend among the Ogre/Mogre community :)

zarfius

13-03-2012 00:23:07

I didn't get around to working on MogreBuilder last week because I was busy working on my own game. I was working on a constructive solid geometry alogoritm (CSG) and it took a lot longer than I expected. For those that are interested you can see some screenshots on my blog :)
http://www.craftworkgames.com/blog/leve ... ctive-csg/

This will probably make it's way into my Glue Editor at some point.

Beauty

13-03-2012 21:27:02

Zarifus, don't worry about a few days or even weeks.
Most important is that you are still on the way to do some steps from time to time. 8)

Your constructive solid geometry is interesting.
Thanks for your blog report!

zarfius

14-03-2012 01:48:00

Zarifus, don't worry about a few days or even weeks.
Most important is that you are still on the way to do some steps from time to time. 8)

Thanks. There is always a lot to do and I can't do it all even when I want too :)

Beauty

16-03-2012 12:08:22

About the Mogre samples.
(Not im portant. Just for information.)


Today I searched for something in the Mogre source codes.
For this I looked to the old frozen SVN repository (Sourceforge, here) and the current HG repository (BitBucket).
There I recognized that the samples previously were placed in "trunk\Mogre\Samples" (as I see in the old SVN repository).
I suppose user GantZ removed them. (He improved Mogre and uploaded the code to his private bitBucket. Later his code was used for the initial revision of our new official Mogre repository.)
In our current repository the file MogreSamples.sln still consists, although it references to dead directories. ..... Now I removed the file.

---------
Additionally I added username aliases to our BitBucket repository.
So we see the real user names and have a quicklink to their profiles.
(Previously there were only cryptic names like "dad@dad-pc".)

zarfius

16-03-2012 12:27:11

Additionally I added username aliases to our BitBucket repository.
So we see the real user names and have a quicklink to their profiles.
(Previously there were only cryptic names like "dad@dad-pc".)

Cool. I was wondering how to fix that.

Beauty

16-03-2012 21:24:33

This week I have a problem with an Ogre related bug, which causes a deadlock. (endless loop)
To fix the bug I need to build Ogre/Mogre again.
So I had a motivation to try out the great MogreBuilder tool.

Unfortunately the automatic build process failed. (on Win7, 64bit, VS 2010 Ultimate)
Details are in the screenshot. If you need more details, just tell me where to find it.

Translation for the yellow message:
Can't open input file "dxguid.lib".

Update (the following text was added later)

This file doesn't exist on my whole hard drives. (HG download problem?)

As I read, this file is a part of the DirectX SDK.
Unfortunately I don't find a seperate download link. (Only the SDK installer with 500MB. To download/install this would be overkill.)
How should be handle it?
Is it allowed to upload a copy of this file to the web? (e.g. to our repository)
Perhaps we need different versions of this file? (x86, x64, ...)




By the way:
Is the BuildConfiguration "Debug" currently supported?
(I saw the parameter in the config file. A debug version could be usable for debugging inside the Ogre core.)

Beauty

16-03-2012 22:34:01

Ideas for the MogreBuilder:
  1. If started without parameter: Show syntax or more detailed help (e.g. loaded from a text file)[/*:m]
  2. Show the time of duration when ready (not necessary, but could interesting)[/*:m]
  3. Possibility to add the target path into the config file[/*:m]
  4. An option for priority (for the main application or just helper files like cl.exe ?)[/*:m]
  5. Add a beep/sound and/or taskbar highlighting, which raises when the build process is ready (Useful when the build window is in background.)[/*:m]
  6. At part "Downloading Ogre Depencies": Don't print so many dots :mrgreen: [/*:m][/list:u]

    And a compliment:
    I like the colour highlighting of the console :D

zarfius

17-03-2012 10:18:08

As I read, this file is a part of the DirectX SDK.
Unfortunately I don't find a seperate download link. (Only the SDK installer with 500MB. To download/install this would be overkill.)

I think you need the DirectX SDK to build Ogre. I'm not sure if there is any other way around it.
Oddly enough I just tried finding the download link from Microsoft and the website is down :-S

How should be handle it?
Is it allowed to upload a copy of this file to the web? (e.g. to our repository)
Perhaps we need different versions of this file? (x86, x64, ...)

I don't think you could solve it this way. You'll probably need more than just this file. If you do manage to get just this file, it'll probably error somewhere else.

Is the BuildConfiguration "Debug" currently supported?
(I saw the parameter in the config file. A debug version could be usable for debugging inside the Ogre core.)

Yes, you can do a debug and release build currently. I've only tried x86 but it *might* also be possible to do x64 if you use Cygons solution files.

This week I have a problem with an Ogre related bug, which causes a deadlock. (endless loop)
What's the problem that causes a deadlock?

Ideas for the MogreBuilder:

If started without parameter: Show syntax or more detailed help (e.g. loaded from a text file)
Show the time of duration when ready (not necessary, but could interesting)
Possibility to add the target path into the config file
An option for priority (for the main application or just helper files like cl.exe ?)
Add a beep/sound and/or taskbar highlighting, which raises when the build process is ready (Useful when the build window is in background.)
At part "Downloading Ogre Depencies": Don't print so many dots :mrgreen:

Some good ideas. I'm not sure what they all mean though (particularly the option for priority?). Due to my limited time I'm only going to focus on things that add real value to Mogre. If you want to add them to the issues list on bitbucket please do, but I don't see anything in this list that adds a lot of value. Maybe someone else is interested in helping?

When I first started looking at MogreBuilder I wanted to add a GUI but the more I thought about it the more I realised that a GUI doesn't really add a lot of value. Sure, console applications are not as "pretty" but when it comes to build tools the console works just fine. You can setup different build configurations in files and run them one after another each time a new version of Ogre comes out. A GUI also provides a little bit of intrinsic documentation because it helps show what options are available, but it comes at a high development and maintenence cost. Documenting the config options directly in the config file works just as well.

Here are the tasks I believe to be the highest priority at the moment (taken from bitbucket) because they directly affect the resulting Mogre.dll:
#6: Include the XML commentation tool in the build process
#7: Fix the issue that causes Mogre to require Terrain and Paging DLL's when your not using them

Tubulii

17-03-2012 16:14:05

I'm not sure what they all mean though (particularly the option for priority?)
I think he means the process priority. Processes can have different priorities and therefore have a different cpu load. If you want to compile mogre in the background, the lowest priority is your friend. If you want to compile it as fast as possible, use priority "real time".

Beauty

17-03-2012 18:26:31

I think you need the DirectX SDK to build Ogre. I'm not sure if there is any other way around it.
In this case you should add the DirectX SDK to the requirement list.

One more idea:
The MogreBuilder could create a text file, which contains some build information.
For example the used DirectX Redistributable revision (e.g. February 2010), the VisualStudio version etc.
Perhaps this would be something like an automatic requirement list.
Also the file could contain information like x86/x64, .NET version.
The result: When the build Mogre binaries are published, the user can quickly see important details.

You'll probably need more than just this file.
For this case we could use the free tool Process Monitor.
(It's one of many "Sysinternals" tools of two Russion developers. Now they work for Microsoft and their tools are owned by Microsoft.)
The process monitor logs all file and registry accesses. Well, a huge amount of information, but with the filters you can focus to the needed information. In your case we would filter the accesses of the used build processes.
It's also a nice tool if you have application problems. (e.g. missing files or registry entries)

What's the problem that causes a deadlock?
It happens when I call RaySceneQuery.Execute(). Normally this works well. But in my current scene I have an origin/direction, when I always get a deadlock. I could find out how to debug inside the Ogre sources. The problem is a while loop (in the terrain scene manager), which never reach the exit condition. On Monday I will look to it again and hope to find out the reason.

I'm not sure what they all mean though (particularly the option for priority?)
I suppose some stages of the build process will cause heavy CPU load. This could disturb the user, when he want to work with other applications. If the priority for the build process is low or even idle, the users isn't disturbed.
If you don't understand other points, just tell me which one.

Maybe someone else is interested in helping?
I would do it if I find some time and motivation.
Before I thought it's good to tell you my ideas. It's better that just doing something, what others don't like.

Due to my limited time I'm only going to focus on things that add real value to Mogre.
I fully agree. On the other hand I have less knowledge about the build internals. So I can't help much in this point.

Terrain and Paging
A question about that:
For my application I need the Terrain Scene Manager.
In a forum topic I read that there are name conflicts with the new Terrain component.
What's about the current MogreBuilder result? Does it still contain the Terrain Scene Manager?
(I suppose the answer is true for Ogre 1.7 sources).

If you want to compile it as fast as possible, use priority "real time".
To use "real time" is very bad for a full load process. This can cause that you can't do anything on the computer until it's ready. Better would be "Above Normal" or "High" instead. Well, a useful command-line option would offer different priority levels.
I can try to include the priority option. Which processes cause the heavy load? Just "cl.exe" or also others?


An other topic:
Today I got an e-mail from a maintainer of ogreci.org. They want to set up a server, which creates nightly build of Ogre for all platforms.
He offers to create nightly builds for Mogre, too.
Sounds interesting. It would be a good working place for the MogreBuilder.
(At least under Windows. Does anybody know it the MogreBuilder would also work with Mono under Linux?)
What do you think about the nightly builds server?

zarfius

18-03-2012 11:11:28

In this case you should add the DirectX SDK to the requirement list.
Yes your right. I assumed that anyone using Ogre / Mogre would already have it. Rather than duplicating the documentation though, I think a simple link to the Ogre prerequisites should suffice.
http://www.ogre3d.org/tikiwiki/Prerequi ... irectX_SDK

Looking at your error a little closer after reading the prerequisites for Ogre I think the problem is with OIS not Ogre. So in theory you might be able to get Mogre to build without the DirectX SDK if you turn off OIS and the DirectX rendering plugin. This probably means fiddling with CMake which I don't know much about.

One more idea:
The MogreBuilder could create a text file, which contains some build information.

It's a good idea but I have no idea how to do it.

For this case we could use the free tool Process Monitor.
Maybe. I'm not sure if Process Monitor would help here, I thought it only showed missing files when a process is running.
In my opinion, downloading the DirectX SDK is always going to be the easiest option. I know it's a big download but it's the easiest and fastest way to solve the problem unless it's going to affect your internet cost.

I would do it if I find some time and motivation.
Before I thought it's good to tell you my ideas. It's better that just doing something, what others don't like.

Idea's are good :) The hardest part is keeping track of them all and obviously finding the time to do them. I think the most important thing is that they are added to the issues list on bitbucket so they don't get forgotten.

I fully agree. On the other hand I have less knowledge about the build internals. So I can't help much in this point.
Any help is better than none. You already do plenty around here Beauty ;)

In a forum topic I read that there are name conflicts with the new Terrain component.
What's about the current MogreBuilder result? Does it still contain the Terrain Scene Manager?
(I suppose the answer is true for Ogre 1.7 sources).

I have no idea. I didn't do anything special to deal with this issue so it either still exists or someone else sorted it out. Did Cygons binaries have this problem? The only way to be sure is to test it.

Today I got an e-mail from a maintainer of ogreci.org. They want to set up a server, which creates nightly build of Ogre for all platforms.
He offers to create nightly builds for Mogre, too.
Sounds interesting. It would be a good working place for the MogreBuilder.
What do you think about the nightly builds server?

This is fantastic news :D This is the real strength of MogreBuilder and arguably the best reason to have it. In fact, until MogreBuilder came along I don't think it would have even been possible to do automated builds of Mogre. It means we can always have up to date Mogre binaries be alerted of build problems as soon as they arise.

(At least under Windows. Does anybody know it the MogreBuilder would also work with Mono under Linux?)
I've never tried building Mogre on Mono but from what I've read Mono should be able to handle any .NET console application so MogreBuilder should work fine.

Beauty

18-03-2012 17:55:53

Good news!
I could build Mogre and the binaries work with my application. :D



Now in detail:

I installed the latest DirectX SDK (June 2010).
At the end was an installation error. Also the second try failed. (see screenshot)
Nevertheless now I had no more "file not found" problems.


The debug version of OIS wasn't found.
I don't know if this is an issue of the MogreBuilder. (Does the builder compiles OIS, too?)


Perhaps there is a problem for 3 classes. (Or is it just a note for the missing subdirectory?)
We could add a task to the MogreBuilder, to create this directory before. So there is red coloured message (which looks like an error).


Then I replaced the binaries of my main application.
(In detail: It was a modified copy, which I created many months ago to test the Cygon builds. The Cygon builds worked fine.)
Unfortunately my application didn't start. So I opened the project in Visual Studio.
The problem was: My MogreNewt.dll is linked against and other Mogre build (Cygon) and causes a conflict.
Currently the MogreBuilder doesn't compile the MogreNewt wrapper.
So I modified my application copy and removed all MogreNewt calls.
When I was ready, my application started fine with the binaries of the MogreBuilder.
That's my story of today.

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

There are more Ogre build Prerequisites in the wiki (MinGW and Boost), but I installed nothing more than VS, .NET, TortoiseHG and DirectX SDK.
Just for information.

Does the used tools (e.g. Doxygen) generate logfiles?
In this case they can be written to the target directiory.
This could be useful for analysis if there are problems.

While the MogreBuilder was running, I watched the Process Explorer (an improved task manager by Sysinternals) and listed all files, which cause significant CPU load. So we know which ones have to be touched for the priority option.
cl.exe
doxygen.exe
link.exe
mspdbsrv.exe



I assumed that anyone using Ogre / Mogre would already have it.
Until today I had no need for the DirectX SDK. (I never tried to compile Ogre.)
Yes, put it to the requirement list.

I know it's a big download but it's the easiest and fastest way
It's useful for many people, but not for all. Even in high-tec Germany there are about 10% of buildings, without high-speed internet connection. (When I lived in a village I had only 64 kBit/s and had to pay every online minute.) Well, now in Germany the government force the mobil telecommunication companies to improve their infrastructure in the "dead zones" (by "LTE" technology).
Nevertheless I'm shure that there are still people in the world, which have only slow internet connection.
(When I travelled in India, it was even a pain to receive and e-mails.)
It is no high priority to focus on that point, but we should keep it in mind.
The x86 libs of the DirectX SDK are only 8 MB. If this is all we need for the build process, it would an option to offer them aside the SDK installer. (If we are allowed to do so.)

Good would be to test the MogreBuilder of a fresh Windows 7.
There we find out all the needed requirements.

I'm not sure if Process Monitor would help here, I thought it only showed missing files when a process is running.
This is just one possebility of the process monitor. (If you set the filter to just show failed accesses.)

I think the most important thing is that they are added to the issues list on bitbucket so they don't get forgotten.
Good point. I should do that.

The only way to be sure is to test it.
My test showed, that the Terrain Scene Manager is still supported. :D

zarfius

18-03-2012 22:40:48

What an excellent detailed response Beauty :) I'm not sure why the DirectX SDK installation failed but everything else can be added to the bitbucket issues list.

Zonder

19-03-2012 10:33:53

The DX error is something to do with your machine I found this on connect

http://answers.microsoft.com/en-us/wind ... 65ff5b3a37

Changing the process priority to real time is bad as it can prevent OS services getting CPU time. For normal applications Above Normal/High is the best option. But the usual limiting factor isn't the CPU it's actually your hard drive speed due to the amount of read/writing that goes on during a build.

And I agree with zarfius the DX SDK should be installed on the build machine

GantZ

19-03-2012 16:45:21

Just a quick note about MogreNewt, since there is some confusion about how it's built, and where is the source code :

  1. The last version of MogreNewt is on the mogreAddons repository over bitbucket, it worked with newton 2.25[/*:m]
  2. Last time I built it, no version of newton were available for vs10. now that newton is open source, you probably can build it for vs10.[/*:m]
  3. The repository for the newton source code is available over googlecode : http://code.google.com/p/newton-dynamics/[/*:m]
  4. The build of MogreNewt is pretty straightforward, just compile it directly using visual studio,or use msbuild to automate the process. you need to download the newtonsdk first, assure yourself that you target the last mogre lib file. It's build like most of the plugins outside of the ogre project range (hydrax, caelum, skyx, etc...)[/*:m][/list:u]

    You can use the existing vc9 project file as a reference if you want to build it for vc10.

    If you have any problem while integrating it in you build process, you can ask me for more information, I haven't built it in a while, but I hopefully can remember how it worked :)

Beauty

19-03-2012 20:59:40

But the usual limiting factor isn't the CPU it's actually your hard drive speed due to the amount of read/writing that goes on during a build.
I watched to the process explorer all the time on my secondary monitor. There are some stages of the process, which are fully CPU consuming for a longer time. I have a dual-core processor and at one time even 3 instances of a process were working with heavy load. Perhaps there are stages, where the hard drive is the break, but not at all. So I think it's a useful task, when I look how to slow down the worker processes.
Just for information. 8)

What an excellent detailed response Beauty :)
You, Amirabiri and McDonte put so much work to this so much important tool.
It would be a shame if nobody would try it.
Reports are also important to find out problems, which doesn't exist on the developers system.

I'm not sure why the DirectX SDK installation failed but everything else can be added to the bitbucket issues list.
The DX error is something to do with your machine I found this on connect
Thanks for the note. The microsoft page explains how to apply several changes to the registry. I don't like to do that.
I don't care about the error. If I remember right, the SDK installation was finished. It was just other additional software, which should be installed by the SDK installer. It doesn't seem to be important for the MogreBuilder.

Just a quick note about MogreNewt
Great!!
Thank you, GantZ. :D

Long time ago I read about problems with compiling for VS 2010. I thought in the meantime the problems should be solved.
Nevertheless I could use the precompiled MogreNewt binaries (e.g. from the Cygon builds).
Perhaps just building Newton causes problems, but not the resulting library file?

The complete Newton sources are public now?
Very interesting.
I did recognised (many months ago) that a few Newton classes were published. Either I misunderstood that news or the Newton developer changed his mind later.

How should we integrate Newton?
Options are: Building the Newton sources or use the precompiled Newton library (note: use the "correct" file of the about 6 newton library outputs).
I think building MogreNewt from a precompiled library would be fine.
It's less complex (lesser possible conflicts to handle) and additionaly there can be conflicts if the Newton API changes.
Perhaps we should put the "correct" Newton library directly to the MogreNewt repository? (Under the condition that it's allowed by the license.)
What do you think? What's your proposal how to embedd MogreNewt to the MogreBuilder?

Beauty

19-03-2012 21:41:32

I wanted to add the DirecX SDK to the requirement list on the front page of the MogreBuilder repository. Unfortunately I couldn't find out how to do that.
Zarifus, can you give me a hint?

zarfius

20-03-2012 05:56:06

I wanted to add the DirecX SDK to the requirement list on the front page of the MogreBuilder repository. Unfortunately I couldn't find out how to do that.
Zarifus, can you give me a hint?

Hey Beauty, I saw your message this morning but got busy at work and forgot all about it.

Updating the front page of a bitbucket repository is actually very easy, but not obvious. The first time I did it was actually by accident. All you need to do is update the Readme.txt file in the source code and bitbucket automatically picks up your changes once you commit.
https://bitbucket.org/mogre/mogrebuilde ... ReadMe.txt

Just a quick note about MogreNewt, since there is some confusion about how it's built, and where is the source code :
Thanks for the detailed notes GantZ :) I'm sure this will come in very useful when someone gets around to including MogreNewt.

Beauty

20-03-2012 19:50:35

Install Microsoft Visual C# 2010 Express.
In the case that somebody has no installed Visual Studio.
Are you shure it's enough to install Visual C# Express?
I suppose the user also needs Visual C++ Express, because of the C++ compiler/linker.


I installed the DirectX SDK of June 2010 and there was no problem with the MogreBuilder.
Later I read in the Ogre build prerequisites, that they purpose the SDK of February 2010.
But I'm not shure if it still could cause hidden problems or if the wiki page just wasn't updated (for a longer time).
Which SDK release I should propose in the readme file?

Beauty

20-03-2012 23:13:27

Cygon wrapped Mogre in the famous Cygon builds.
In his bundle he also included MogreNewt (compiled against Newton 2.33).

Also I found an important note:

* Updated MogreNewt to work with Newton 2.33, also fixed a minor bug in the wrapper

Zarifus, you said that you received ALL files from Cygons harddrive, which are related to the Mogre builds.
Can you please send me a copy of his MogreNewt stuff?
Then I can search for the changes and add it to the repository.
My e-mail address is beautyod at gmx.de

zarfius

20-03-2012 23:59:47

Can you please send me a copy of his MogreNewt stuff?
Then I can search for the changes and add it to the repository.

I've sent you a link. Check your private messages.

From what GantZ wrote about building MogreNewt I gather we can have it as an optional build step *after* the main Mogre.dll is built. I think this is important because many people (myself included) don't need MogreNewt and will probably want to skip it. It probably won't be particularly difficult but it's just something to think about if you intend to add it.

In the case that somebody has no installed Visual Studio.
Are you shure it's enough to install Visual C# Express?
I suppose the user also needs Visual C++ Express, because of the C++ compiler/linker.

You're probably right about that. I have Visual C++ Express on my machine but didn't really think about it's involvement in the build process. Of course, there might be other ways to build it even without Visual Studio (using Mono for example). We probably don't need to list all of the different configurations. I think it's helpful to know how to build it with the express versions because they are free.

I installed the DirectX SDK of June 2010 and there was no problem with the MogreBuilder.
Later I read in the Ogre build prerequisites, that they purpose the SDK of February 2010.
But I'm not shure if it still could cause hidden problems or if the wiki page just wasn't updated (for a longer time).
Which SDK release I should propose in the readme file?

I normally go for the latest release of the SDK. It's probably not easy to figure out exactly which minimum version of the SDK you need. If you can that's great, otherwise just update the readme file with whatever version you used because you know it works. Keep in mind that the DirectX SDK is really a requirement of parts of Ogre and may change when the Ogre team changes things.

Beauty

21-03-2012 03:14:59

Note: This post is only about MogreNewt

MogreNewt is open source for 1 month now.

I found a note related MogreNewt and VS 2010:
12/29/2010
Revert back to Visual studion 2008
Visual studio 2010 is too buggy for prime time, it is no backwrodk compatible, and it teh bash build funtionality doe no work at all,
This may be the last version of Newton using Visual studio, futher version will use eithr GCC or Intel compiler
Thsi s a prublic service for those hwo are on teh fance and wnat to buy Visual studio 2010, please do not.
Give yor self a favor and do not waste you money byu visual stiduo 2010, because it is useless for anything more complex than a "Hello world program"


MogreNewt binaries (currently 2.35) are here:
http://code.google.com/p/newton-dynamics/downloads/list

Also very interesting:
The Newton API shouldn't change anymore for Newton 2, because now there will be only bugfixes.
New features will be added to Newton 3 instead.
As a result our wrapper should be compatible for further Newton 2 releases. 8)


So, now I needed almost 4 hours to compile MogreNewt.
Or more precise: Almost 4 hours to update linker paths and to find the needed files.
With the tool Process Monitor I could find out that the build process tries to find a specific Mogre file in the path "C:\Program Files (x86)\boost\boost_1_40". Ok, this confusion (bad setting) was solved, too.

All path changes/additions I applied directly to the project file by a text editor. Additionally I documented every change to a text file.
The problem were the usage of absolute paths.
My intention was to replace them by local paths and to make it easy for "users" to add the needed files.
I created a directory structor for different kind of depencies and will add "what to add here.txt" files with further information.
This should also be a good basis to integrate MogreNewt to the MogreBuilder.

Honestly, I couldn't compile MogreNewt today.
The reason: The Newton API changed for a few functions. I hope it will work with the updated files of Cygon. (Zarifus, please don't forget to send them to me.)

Now it's 4:15 o'clock at night. I'm very tired and wanted to be in my bed 3 hours before.
That's it for today ...

zarfius

21-03-2012 05:38:39

I found a note related MogreNewt and VS 2010:
Newton developer wrote:12/29/2010
Revert back to Visual studion 2008
Visual studio 2010 is too buggy for prime time, it is no backwrodk compatible, and it teh bash build funtionality doe no work at all,
This may be the last version of Newton using Visual studio, futher version will use eithr GCC or Intel compiler
Thsi s a prublic service for those hwo are on teh fance and wnat to buy Visual studio 2010, please do not.
Give yor self a favor and do not waste you money byu visual stiduo 2010, because it is useless for anything more complex than a "Hello world program"

I find this very hard to believe. Visual Studio 2010 is perfectly okay to use for most purposes. Perhaps Newton has some incompatibilies but that's no reason to go back to the 2008 version. It means that Newton is going to have trouble moving forward if they don't sort these issues out, or at least for anyone who wants to compile Newton with VS2010 for whatever reason. There are other other good physics engines to choose from that work perfectly well with VS2010. In my opinion, you should be very careful if you want to continue to use Newton for the long term.

The reason: The Newton API changed for a few functions. I hope it will work with the updated files of Cygon. (Zarifus, please don't forget to send them to me.)
Check your private messages on the Mogre forums. I have already sent you a link.

Honestly, I couldn't compile MogreNewt today.
Good effort anyway. I'm sure you'll sort it out.

Beauty

21-03-2012 12:38:34

I've sent you a link. Check your private messages.
Good boy.

optional build step *after* the main Mogre.dll is built.
This was my intension.

You're probably right about that. I have Visual C++ Express on my machine but didn't really think about it's involvement in the build process.
I will add it to the readme file (and upload it with futher additions).

I find this very hard to believe.
I don't care about building Newton myself. Perhaps the Newton developer tried an early VS 2010 version and had problems with a bug.
It seems so that we just need to use the precompiled binaries. Newton in general works well (as I read).

In my opinion, you should be very careful if you want to continue to use Newton for the long term.
I will stay with Newton. For my application I need only the collision detection functionality. By my suggestion, Julio (Newton developer) added specific query functions to Newton. This was very important for my sonar simulation, which needs very high-performance collision detection queries.
For me Newton is fine and there is no need to try out other libraries. (Additionaly I don't have the time. I have to focus to my diploma thesis.)

Beauty

22-03-2012 01:32:41

Unfortunately the archive file cygon-mogre-sources-1.7.3.7z doesn't contain anything related Newton or MogreNewt.
I will ask Cygon.


Today I tried the MogreBuilder at the computer on my working place.
The DirectX SDK installation was successful.
But the build failed.
The error message: "device not found" (or maybe is was "device not accessable")
Well, this message said nothing to me.

I looked into the sources and created a seperate solution and project file for debugging. (Simulate command line calls with parameters)
So I can debug with individual arguments (and config file) withouth making dirty the "original" project/solution file.

The reason of the "drive not found" message was, that I didn't change the path parameter and the drive F:\ doesn't exists on my working place pc.
An other time I forgot the path parameter and added only the config file arguments. Again I got a useless error message.

At this point I decided to add some security checks and started to make additions.
I will upload them and tell you when I'm ready.

Now I go to my bed. A little bit more early than yesterday. :mrgreen:

Beauty

22-03-2012 13:35:06

The error message: "device not found" (or maybe is was "device not accessable")
I'm on work again and saw the screenshot. The message was:

Checking out the source code of Mogre (please be patient)
The device is not ready to use

Realy confusing abort message for an invalid target path.
This is improved now.


Today I changed the argument parsing.
* The path is optional (Gives the possibility to define the target path by the config file in the future.)
* The order of config options doesn't care (useful when we add more)
* If an option can't be assigned, there is a warning and the user will be asked if he want to skip.

Beauty

22-03-2012 18:01:36

As result of a further error (because I used a path which includes spaces)
I added support for paths with spaces. In this case the path has to put in quotes.

I recognised:
When the Ogre sources are still in the target directory, they will not be updated by TortoiseHg.
This could be well in many cases, but I think it would be useful to offer an option to let them synchronise.
Or perhaps enable synchronisation by default?

Tiny addition:
I added a few lines of code. Now the duration time will be displayed.

There is a warning, that the file "Main\OgreSWrc\ogre\Depencies\bin\debug\cg.dll" does not exist.
I suppose CG is important (maybe for shaders?)


It's bad that I can't run the whole build process from Visual Studio. (For debugging.)
CMake doesn't like it.



There were problems to apply the patches of Cygon.
I'm not shure it this also happened at my home computer.

In the case that the problems are not on my home computer there can be 2 reasons:
* My target path (on work computer) contains a space.
* My target path is different than my path at home.
I made copy and paste the files from my home computer to avoid redundant downloads.
Then I deleted the directory Main\OgreSrc\build, because CMake didn't like the changed path.


Beauty

22-03-2012 22:30:35

Ok, at home I continued my tests.
Using the MogreBuilder again on my home computer caused problems, too.

I couldn't remeber that I had such problems at my first run.
So I decided to use a new target directory and perform everything again, including the time-consuming source downloading process.

Results:
  1. Patching works fine. [/*:m]
  2. There is no warning about a missing cg.dll file. [/*:m]
  3. The few problems of my first build report still contains.[/*:m]
  4. Additionally I replaced 2 Ogre files. - Directly after download and before wrapping/building. (This should bugfix my Ogre related deadlock problem.)[/*:m][/list:u]

    Ok, to be honest:
    The build process failed near the end, because it seems so that my bugfixed *.cpp files contains a syntax error.
    But it shows that there seems to be a difference between a first run (empty target directiory) and a following run.

    I will test is again.
    With the same, unchanged target directory.
    .....
    Now it's done.
    Result:
    1. When MogreBuilder uses an empty target directory, the result is almost fine. [/*:m]
    2. When MogreBuilder runs again (using a previously used target directory), then there are errors. [/*:m][/list:u]

      Problems, which only happened on the second run:
      1. File cg.dll not found in directory Main/OgreSrc/ogre/Dependencies/bin/debug[/*:m]
      2. Errors at applying Cygon patch[/*:m][/list:u]

        Oh, wait - now I see a "non-highlighted" output information, which could be related to the cg.dll problem:
        (I don't know if they only happens at the second run. There are so many non-highlighted outputs.)

        Running CMake on Ogre source tree
        ...
        -- Looking for Cg...
        -- Found Cg: F:/Ogre/MogreBuilder__Result_2/Main/OgreSrc/ogre/Dependencies/lib/release/cg.lib
        -- Looking for POCO...
        -- Could not locate POCO
        -- Looking for TBB...
        -- Could not locate TBB
        -- Looking for OIS...
        -- Found OIS: F:/Ogre/MogreBuilder__Result_2/Main/OgreSrc/ogre/Dependencies/lib/release/OIS.lib
        -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
        -- Looking for CppUnit...
        -- Could not locate CppUnit...


        There is also this red coloured message (only in the second run?)
        + boost-date_time: Used for threading support <http://boost.org>;


        One more I recognised:
        I aborted the MogreBuilder, but the 2 compiler threads of "cl.exe" are still working (with full CPU load).
        Good would be to find a way to abort/kill the "helper processes" when the main application was aborted.

        Useful would be a way to write a copy of all outputs to a logfile.
        Does anybody has an idea how to grabb console outputs of helper processes?
        If yes, I also could add a filter, which highlights warnings of errors of helper processes (e.g. CMake). Currently the outputs are only in grey colour.

        As long as we don't solve the problems with a second run, it would be nice to have an option to cleanup everything - except the time-consuming downloads.

        Thats my report for now.
        For today I have no more motivation at MogreBuilder.
        Perhaps now I look to the Newton wrapper instead.

Beauty

22-03-2012 23:55:49

I continued to spend my time on the MogreBuilder.
My current state I uploaded to the repository and described the changes.

Enough for today! :twisted:

zarfius

23-03-2012 01:20:47

As result of a further error (because I used a path which includes spaces)
I added support for paths with spaces. In this case the path has to put in quotes.

Good idea. I normally use paths without spaces to avoid this problem, but I agree it's much better to have the applicaiton deal with spaces correctly.

When the Ogre sources are still in the target directory, they will not be updated by TortoiseHg.
This could be well in many cases, but I think it would be useful to offer an option to let them synchronise.
Or perhaps enable synchronisation by default?

Yeah it would be good to synchronise. It think doing it by default is okay. Sometimes you will want to start clean with an emptry directory but that's always pretty easy to do (just delete it). On the other hand, downloading the sources every time is very painful and it would be nice to be able to avoid it.

One option I had considered but haven't tried is to have a local copy of the repository on your hard drive and point the repository URL to it in the configuration file. This way, the MogreBuilder will work just the same but rather than downloading from the internet it will just "download" from another location on your hard drive.

It's bad that I can't run the whole build process from Visual Studio. (For debugging.)
CMake doesn't like it.

I'm not sure why you can't run MogreBuilder from Visual Studio. That's what I always do.

There were problems to apply the patches of Cygon.
It looks like the error is just telling you the patch is already applied. I don't think you need to worry about it. It probably should be displayed as a warning because the build should still succeed.

The build process failed near the end, because it seems so that my bugfixed *.cpp files contains a syntax error.
What .cpp files did you bugfix?

Useful would be a way to write a copy of all outputs to a logfile.
Does anybody has an idea how to grabb console outputs of helper processes?

Yes, outputting to a log file is something I want to do as well. I tried grabbing the output of each process once but some of them don't play nicely (hg from memory). I think all of the output runs through the OutputManager class so you should be able to log it to a file with a few lines of code.

* If an option can't be assigned, there is a warning and the user will be asked if he want to skip.
Just be careful prompting the user. This can cause problems when we automate the build process in a continuous integration server because the automated process can't answer questions ;) It would probably be better to just output a message and exit with an error code.

For today I have no more motivation at MogreBuilder.
Enough for today! :twisted:
Working on MogreBuilder is long and draining because of how long it takes to build Mogre. That's why I've been taking a break for a while. I'm happy to help with advice though :)

Great job with what you've done though! :D I just had a look over your checkin and I'm pleased overall. Some of the issues can be crossed off the list.

Zonder

23-03-2012 12:36:12

Don't forget to monitor standard error as well as normal console output sometimes command line tools use it.

http://msdn.microsoft.com/en-us/library ... error.aspx

Beauty

23-03-2012 16:07:57

Sometimes you will want to start clean with an emptry directory but that's always pretty easy to do (just delete it).
We could add a clean up option, which delete the content of the target directory.
What's your proposal for the option name?
Maybe "-cleanup"?

to have a local copy of the repository on your hard drive and point the repository URL
The same idea came into my mind just one minute ago. I will try it.

Just be careful prompting the user. This can cause problems when we automate the build process in a continuous integration server because the automated process can't answer questions ;) It would probably be better to just output a message and exit with an error code.
That's right. Removing/aborting is one solution.
For home use the would be OK, because the user interaction is just after the start.
An other idea: Use a time out and default answer. This would be fine for the server and for optional user interaction while running.

Beauty

23-03-2012 23:55:56

to have a local copy of the repository on your hard drive and point the repository URL
Oh yes, this works fine like an ultra turbo.

Additionally the build/wrapping was successful. (Duration: 59 minutes)
I used an empty target directory.


I'm not sure why you can't run MogreBuilder from Visual Studio. That's what I always do.
On yesterday I made a screenshot of it:


By your motivation I tried it again and now it works.
Perhaps this is an error that only happens partially.



New feature: Priority control

By default the worker processes with high CPU load becomes the priority "BelowNormal".
For this task an additional thread is used. It watches out for the processes and adjust them quickly after they started.
The priority of MogreBuilder itself and the HG process stay normal. (Cause not much CPU load.)

Also I added a command line option to use an other priority.
Example:

MogreBuilder.exe c:\myPath -config myConfig.cfg -priority idle

As result of my improved argument parsing the options order doesn't matter.
So this would also work:

MogreBuilder.exe c:\myPath -priority idle -config myConfig.cfg





The exact dependencies are:
...
  1. An SSE2-capable CPU (I enabled it in all projects since it improves performance and I think all Pentium IIIs and Athlon XPs have been phased out by now)[/*:m][/list:u]

By default it's useful to use this settings.
Maybe for some users it's important to support old computers, too.
If possible (with less amount of time) we could offer an option for that case.
Maybe it's just needed to modify one line in a CMake config?




The build process failed near the end, because it seems so that my bugfixed *.cpp files contains a syntax error.

What .cpp files did you bugfix?

It's only a few lines of code in 2 files.
I have bad C++ knowledge and edited without syntax check support.
Details I posted in the topic Bug with RaySceneQuery when almost vertical ray.


Don't forget to monitor standard error as well as normal console output sometimes command line tools use it.
Thanks for your note.
Nice to see that someone else follows this long topic. (Sometimes I feel like to do a monologue :lol: )

Beauty

24-03-2012 00:11:57

There was a request for an option to disable terrain/paging component.
Perhaps this option isn't needed.

Someone should try this:
Delete OgreTerrain.dll and OgreTerrain.dll.
Then run an application (that uses the MogreBuilder binaries) and look if there is a problem.
(Also look to the ogre.log file.)

If there is no problem, then there is no need to waste time on this option.

zarfius

24-03-2012 03:51:13

Wow, your on a role Beauty. You've added a lot of great features since I lasted looked :)

Someone should try this:
Delete OgreTerrain.dll and OgreTerrain.dll.
Then run an application (that uses the MogreBuilder binaries) and look if there is a problem.
(Also look to the ogre.log file.)

Someone reported this as in issue before. I don't think it's been fixed yet.

By your motivation I tried it again and now it works.
Perhaps this is an error that only happens partially.

By the looks of the CMake error I think it just needed to shutdown Visual Studio while it updated a file. Now that the file is up to date it should work fine with Visual Studio open.

Any news on running this thing on the continuous integration server?
http://ogreci.org/

Beauty

24-03-2012 16:14:48

it seems so that my bugfixed *.cpp files contains a syntax error.
I can't figure out the supposed syntax error of my bugfix.
To see compiler errors I cloned the Ogre source code and downgraded it to the 1.7 tip. (Because the buggy TerrainSceneManager files are removed in Ogre 1.8.)
Now I need the visual studio project files to load everything, but there no VS files.
Well, I know, they will be created by CMake, which I never used.

To learn details about CMake I looked to the MogreBuilder. 8)


In the MogreBuilder CMake task I found a possible TODO.
Look to this code snippet:

class OgreCmake : Task
{
// ...
public override void Run()
{
// we always want to do this otherwise switching between configurations fails (e.g. Debug then Release).
Directory.CreateDirectory(inputManager.OgreBuildDirectory);

// ...
}
// ...

Zarifus, is your intention to delete the previous CMake files? (The comment looks like this.)
If so, we need to call a DeleteDirectory() before creating the directory "Main\OgreSrc\build".


Any news on running this thing on the continuous integration server?
http://ogreci.org/

I told him, I will ask the other Mogre users.
Until now he didn't answer for the operation system question.
If they use Linux (what I suppose), somebody should test the MogreBuilder with Mono. Perhaps we have to do some changes for that.

crashtua

24-03-2012 16:28:23

I hawe some problems with terrain demo:

As you can see far parts of terrain are black :(

Beauty

24-03-2012 17:03:11

I wonder how the CMake path is grabbed from the config file.
The default value will be saved to InputManager.CMakeExecutable.
I can't find out where/how it's updated by the config file entry.

By the way:
Currently I create some code to search for cmake.exe in the system variable path automatically. (For the case that it's not found by the default path or the config file entry.)


What I don't like:
Often the word "var" is used to define variables.
It's confusing, because I don't see the real type of the variable and I can't jump to it's definition by F12.
So I will replace the "var" symbols by the related types.
For example: var outputManager; --> ConsoleOutputManager outputManager;

Beauty

24-03-2012 17:42:09

I hawe some problems with terrain demo
As you can see far parts of terrain are black :(

Thanks for trying and your feedback!

Do you also use paging?
It looks like the next terrain tile(s), which are black.

Perhaps we should ask in the Ogre main forum.
There should be many users of the new terrain component, which could get an idea what's the problem.
Would you like to post it in the Ogre main forum?
(If you do so, please give us the URL of the topic.)

Beauty

24-03-2012 17:44:55

Any news on running this thing on the continuous integration server?
What happens if the server uses Linux?
I suppose Visual Studio compilers doesn't run under Linux.
Would there be a way to compile the Mogre stuff?

Beauty

25-03-2012 22:42:22

Today I spent many ours for MogreBuilder.
Here the changes from the Mercurial log:


* Restructured the files
..... * Moved source files to directory "Source"
..... * Moved additional files (e.g. patch.exe) to directory "Source_additions"
--> The will be copied to the binary directoy at compilation time.
(If you add further files to the project, use "add LINKED")
* Changed: When Ogre patch failed, don't abort (Because the patches could already be applied.)
* Removed all "var" declarations by it real data type (Better overview.)


* When ready: Print a summary of all Errors/Warnings (including the related action name)
* When ready: Taskbar highlighting (to get the users notice)
..... * No highlighting if just started (e.g. argument errors)
..... * If window in background: Blink until window get focus
..... * If window in foreground: Static highlight of the window forever
* Window now is title "MogreBuilder"
* Changed console buffer to 9999. So ALL outputs are visible by scrolling up.
* Disabled the priority change messages (because there are many worker threads)
* Updated ReadMe.txt file
* Created file "File overview.txt"


* When ready: Print a summary of all Errors/Warnings (including the related action name)
This I didn't checked yet, because it would take 1 hour of waiting.

Result:
  1. When MogreBuilder uses an empty target directory, the result is almost fine.[/*:m]
  2. When MogreBuilder runs again (using a previously used target directory), then there are errors. [/*:m][/list:u]

There were problems to apply the patches of Cygon.
There were problems to apply the patches of Cygon.

I checked this today. You are right, the build process wasn't disturbed by this.
I removed the warning from the readme file.

zarfius

26-03-2012 00:21:07

Zarifus, is your intention to delete the previous CMake files? (The comment looks like this.)
If so, we need to call a DeleteDirectory() before creating the directory "Main\OgreSrc\build".

My intention was not to delete the CMake files. If I remember correctly, there was a simple bug when that directory did not already exist. The comment wasn't intended as a TODO because the last time I checked it worked. However, if it has introduced a new bug please feel free to change it.

What I don't like:
Often the word "var" is used to define variables.
It's confusing, because I don't see the real type of the variable and I can't jump to it's definition by F12.
So I will replace the "var" symbols by the related types.
For example: var outputManager; --> ConsoleOutputManager outputManager;

I agree :) I hated when they introduced the var keyword into C# because it makes programmers lazy and code harder to read. I must admit though, when I work with code in a big production system all day long I get used to it pretty quickly and I've been guilty of being lazy myself :wink:

What happens if the server uses Linux?
I suppose Visual Studio compilers doesn't run under Linux.
Would there be a way to compile the Mogre stuff?

I wouldn't worry about trying to compile Mogre under linux. Even if you could get it working it's probably not what we want at this stage becuase a binary file compiled under linux is not going to be compatible with Windows. So the real question is, does the CI build server support Windows? I'm sure it could.

Today I spent many ours for MogreBuilder.
You are becoming the maintainer of MogerBuilder the way your going :wink: It's exciting to know that we should be able to keep Mogre up to date with new releases of Ogre.

Beauty

26-03-2012 02:09:41

As I wrote somewhere above, I have a problem with an Ogre bug.
I modified the code, but then I got a syntax error. (I saw it while compiling with MogreBuilder.)

Only by the help of MogreBuilder I could get the Visual Studio files, which I need for syntax checks inside VS. (The VS files are not in the Ogre repository, because they will generated somehow by CMake.)

Additionally: Without the MogreBuilder I would have much trouble (for shure!!) to build Ogre with the fixed bug. The Ogre maintainers don't care about the bug, because the Terrain Scene Manager is removed from Ogre 1.8. But to continue my diploma thesis I have to fix it.

So I'm very very happy about Amirabiri, McDonte and Zarifus. Without your tool MogreBuilder I would have a huge problem.

I'm too stupid for C++. Maybe someone can help me?
Here is the code with the syntax error:

const Vector3& dir = mRay.getDirection();
// ...
dir = Vector3::UNIT_Y; // ERROR HERE

Error message:
Binary operator "=": Can't found an operator or conversion for type "const Ogre::Vector3".

You are becoming the maintainer of MogerBuilder the way your going :wink:
I have less knowledge about wrapping, nor about C++ (as you see above).
I just made some additions, which I can do by my pure C# experiences.

It's exciting to know that we should be able to keep Mogre up to date with new releases of Ogre.
We could make a quick test with Ogre 1.8.
In most easy case we just need to change the "OgreBranch" entry in the config file.

By the way:
How you load the settings of a config file?
On yesterday I couldn't figure out, how you load the cmake path from it.

zarfius

26-03-2012 02:49:40

I'm too stupid for C++. Maybe someone can help me?
Here is the code with the syntax error:
const Vector3& dir = mRay.getDirection();
// ...
dir = Vector3::UNIT_Y; // ERROR HERE

Error message:
Binary operator "=": Can't found an operator or conversion for type "const Ogre::Vector3".

The problem here is that you're trying to modify a 'const' variable. The MSDN documentation says "the const keyword specifies that the object or variable is not modifiable."

I'm pretty sure there is a good reason why the return value of ray.getDirection is declared const, I'm no expert but I suspect you can't simply remove the const keyword from the above code. If I could see the rest of the function maybe I can help more?

We could make a quick test with Ogre 1.8.
In most easy case we just need to change the "OgreBranch" entry in the config file.

I was thinking that too. I just don't have any need to try it right now.

How you load the settings of a config file?
Settings are loaded with the magic of reflection. This method is located in the InputManager class. It loads the settings from the config file into a Dictionary and assigns the values to the properties of the InputManager using the property info reflection method. What would you like to change?

public void LoadConfig(string configFile)
{
Dictionary<string, string> dictionary = LoadKeyValueDictionary(configFile);

foreach (PropertyInfo propertyInfo in GetType().GetProperties())
{
if (dictionary.ContainsKey(propertyInfo.Name))
{
propertyInfo.SetValue(this, dictionary[propertyInfo.Name], null);
}
}
}

Beauty

26-03-2012 11:27:50

Related to Ogre depency files

The MogreBuilder downloads the Ogre depency files from here:
http://surfnet.dl.sourceforge.net/project/ogre/ogre-dependencies-vc%2B%2B/1.7/OgreDependencies_MSVC_20100501.zip

It contains:

Cg-2.2
FreeImage-3.13.1
freetype-2.3.11
ois-1.2.0
zlib-1.2.3
zziplib-0.13.57


Notes of Cygon related to his 1.7 "Cygon builds":
Over the weekend, I've done some builds of Mogre with Ogre 1.7.3 targeting x64. I also decided to build all dependencies from scratch to achieve a homogenous build, so I'm now using Boost 1.47.0, FreeImage 3.15.1 and CG 3.0.

By using this download file, we don't have the newst version (as used for the Cygon builds).
So I propose to update the depency files (related to Ogre/Mogre 1.7), upload a zip file of it to a custom Mogre download location and use this as default depency download for building Mogre 1.7.


It contains the backing code of Boost (date_time, regexp and math). Vanilla Ogre links to Boost as a static library, but then you end up with one additional copy of the Boost code in memory for each Ogre DLL, which I considered wasteful, so I compiled the required parts as a DLL. The "Tr1Boost" name is because it's a minimal subset of Boost, containing only the headers required by Ogre and to support C++ TR1 in Visual C++ 2010 SP1. Only 902 headers instead of 8597 for Boost 1.47 :)

What's about MogreBuilder and Boost?
Does it use the reduced "TR1" version or the "normal" (full) version or no Boost?

tafkag

26-03-2012 11:59:14

Hi everybody,

after building Mogre manually a few times, I wanted to give the MogreBuilder a try, so first of all, thanks for your hard work on this great tool. There seems to be a problem with boost:



Is it possible (command line option?) to build ogre/mogre without the boost dependency?

zarfius

26-03-2012 12:17:54

I propose to update the depency files (related to Ogre/Mogre 1.7), upload a zip file of it to a custom Mogre download location and use this as default depency download for building Mogre 1.7.
Good proposal. Do you know how to do it?

What's about MogreBuilder and Boost?
Does it use the reduced "TR1" version or the "normal" (full) version or no Boost?

I don't think Mogre uses boost at the moment. It might be used for threading of the Terrain and Paging component. I don't know why else it would be needed.

Beauty

26-03-2012 15:51:32


* When ready: Print a summary of all Errors/Warnings (including the related action name)
This I didn't checked yet.

Now this feature is tested. It works well.


Support for paths with spaces:

There were (more) problems while using a path, which contains a space symbol.
The problems were caused by Mercurial.
To handle this case I created the method HgPathSecurity() to make them bullet proof related to Mercurials whishes.
Additionally I needed to update Mercurial (TortoiseHG) to solve the problem.
In the case that a path contains a space symbol and the Mercurial clone fails, the user will get a message for updating Mercurial/TortoiseHG.



after building Mogre manually a few times, I wanted to give the MogreBuilder a try

Thanks for trying MogreBuilder and your report.
It's nice to know, that there people test our work. :D


There seems to be a problem with boost:
Is it possible (command line option?) to build ogre/mogre without the boost dependency?

Strange. I suppose we use the same configuration and code.
So why I don't have a boost error and you have?
Did you change something in the config file?
Did you call MogreBuilder without config file option?
Did you use an other Ogre/Mogre repository? (e.g. with modified source?)

Somewhen I read in the forum, that there is an option in a source file to enable/disable boost.
(I think I read it in the time before Terrain/Paging was available.)
If I remember right, it's possible to build Mogre with boost and also without boost.
(Although I don't understand the sense. Why there is an option for using boost, when Mogre works without, too?)

tafkag

26-03-2012 16:14:23

Strange. I suppose we use the same configuration and code.
So why I don't have a boost error and you have?
Did you change something in the config file?
Did you call MogreBuilder without config file option?
Did you use an other Ogre/Mogre repository? (e.g. with modified source?)


I used the default config file and didn't call the MogreBuilder with any option.

Somewhen I read in the forum, that there is an option in a source file to enable/disable boost.

There's a cmake option OGRE_USE_BOOST which is activated per default on my system when building ogre. Maybe that's not the case on all (your?) system. I added -OGRE_USE_BOOST:BOOL=OFF to OgreCmake.cs to see if this solves the issue. It's building right now so I will report back in a few minutes. ;)

tafkag

26-03-2012 16:23:44

There's a cmake option OGRE_USE_BOOST which is activated per default on my system when building ogre. Maybe that's not the case on all (your?) system. I added -OGRE_USE_BOOST:BOOL=OFF to OgreCmake.cs to see if this solves the issue. It's building right now so I will report back in a few minutes. ;)

Same error - would have been to easy. ;) :(

Beauty

26-03-2012 16:47:10

Related to Boost.

There are these Ogre files with "boost" as part of the file name:
Main\OgreSrc\ogre\OgreMain\include\Threading\OgreThreadDefinesBoost.h
Main\OgreSrc\ogre\OgreMain\include\Threading\OgreThreadHeadersBoost.h


Also there seems to be files that define if Boost ist used:
Main\OgreSrc\ogre\OgreMain\include\Threading\OgreThreadDefines.h
Main\OgreSrc\ogre\OgreMain\include\Threading\OgreThreadHeaders.h


Content of OgreThreadDefines.h:

#ifndef __OgreThreadDefines_H__
#define __OgreThreadDefines_H__

#define OGRE_AUTO_MUTEX_NAME mutex
#if OGRE_THREAD_PROVIDER == 0
#include "OgreThreadDefinesNone.h"
#elif OGRE_THREAD_PROVIDER == 1
#include "OgreThreadDefinesBoost.h"
#elif OGRE_THREAD_PROVIDER == 2
#include "OgreThreadDefinesPoco.h"
#elif OGRE_THREAD_PROVIDER == 3
#include "OgreThreadDefinesTBB.h"
#endif

#endif


Content of OgreThreadHeaders.h:
#ifndef __OgreThreadHeaders_H__
#define __OgreThreadHeaders_H__

#if OGRE_THREAD_PROVIDER == 1
#include "OgreThreadHeadersBoost.h"
#elif OGRE_THREAD_PROVIDER == 2
#include "OgreThreadHeadersPoco.h"
#elif OGRE_THREAD_PROVIDER == 3
#include "OgreThreadHeadersTBB.h"
#endif

#endif


Boost seems to be used for threading.
(I suppose for the multithreading option of Ogre.)


I found something interesting in the outputs of CMake:

// ...
-- Looking for Cg...
-- Cg_PREFIX_PATH changed.
-- Found Cg: D:/Mogre BUILD/MogreBuilder__Result/Main/OgreSrc/ogre/Dependencies/lib/release/cg.lib
-- Looking for POCO...
-- Could not locate POCO
-- Looking for TBB...
-- Could not locate TBB

-- Looking for OIS...
-- OIS_PREFIX_PATH changed.
-- Found OIS: D:/Mogre BUILD/MogreBuilder__Result/Main/OgreSrc/ogre/Dependencies/lib/release/OIS.lib
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Looking for CppUnit...
-- Could not locate CppUnit
--
-----------------------------------------------------------------------------
-- The following external packages were located on your system.
-- This installation will have the extra features provided by these packages.
+ zlib
+ zziplib
+ freeimage
+ freetype
+ OpenGL
+ OpenGL ES
+ DirectX
+ cg
+ OIS
-----------------------------------------------------------------------------
-- The following OPTIONAL packages could NOT be located on your system.
-- Consider installing them to enable more features from this software.
+ boost: Boost (general) <http://boost.org>;
+ boost-thread: Used for threading support <http://boost.org>;
+ boost-date_time: Used for threading support <http://boost.org>;
+ POCO: POCO framework <http://pocoproject.org/>;
+ tbb: Threading Building Blocks <http://www.threadingbuildingblocks.org/>;
+ Doxygen: Tool for building API documentation <http://doxygen.org>;
+ CppUnit: Library for performing unit tests <http://cppunit.sourceforge.net>;
-----------------------------------------------------------------------------


So perhaps CMake searches on the system for an installed Boost (or other threading alternatives.)
If CMake is found, it generates different build configuration files.
This could be the reason why you have problems and we not.


Strange:
CMake sais, Doxygen not found.
But I know there are MogreBuilder outputs, which uses Doxygen.
We should look to that. (Perhaps CMake needs it for generation of the Ogre API.)

Ok, I found it. Doxygen will be downloaded/added to this path of the target directory.
Codegen\cpp2java\bin\doxygen.exe
Perhaps the MogreBuilder can add the directory to the PATH environment variable automatically after cloning the Mogre repository.
(In detail: Just extend the path of the MogreBuilder. Not of the global PATH environment variable.)
If I don't forget it, I try to implement this.

Workaround idea to disable Boost:
Modify the PATH environment variable of the MogreBuilder. (I hope this also will work for the "worker processes" of CMake.)


I hope this small "research report" could help with the further development.

Beauty

26-03-2012 16:51:33

Somewhere in the many MogreBuilder outputs is this section:


FEATURE SUMMARY
----------------------------------------------------------------------------
Building components:
+ Paging
+ Terrain
+ RTShader System
+ RTShader System Core Shaders
+ RTShader System Extensions Shaders
Building plugins:
+ BSP scene manager
+ Cg program manager
+ Octree scene manager
+ Portal connected zone scene manager
+ Particle FX
Building rendersystems:
+ Direct3D 9
+ OpenGL
Building executables:
+ Samples
+ Tools
Building core features:
+ DDS image codec
+ PVRTC image codec
+ FreeImage codec
+ ZIP archives
Build type: dynamic
Threading support: none
Use double precision: disabled
Allocator type: nedmalloc (pooling)
STL containers use allocator: enabled
Strings use allocator: disabled
Memory tracker (debug): disabled
Memory tracker (release): disabled
Use new script compilers: enabled
Use Boost: disabled


It seems so that this feature summary is created by CMake.
It would be nice to grabb this (somehow) and repeat it at the end of the MogreBuilder run.
Not important, but a useful information for users.

Beauty

26-03-2012 16:59:07

Back to Boost again.

It seems to that the Boost configuration will be applied in these files:
(Open them and seach for "boost". Then you will find the related lines of code.)
Main\OgreSrc\ogre\CMake\ConfigureBuild.cmake
Main\OgreSrc\ogre\CMake\Dependencies.cmake
Main\OgreSrc\ogre\CMake\InstallDependencies.cmake


I don't know in detail how CMake works, nor how to apply options in a "regular" way.
(I mean without modifying by external code between downloading and executing them.)

Well, maybe this helps somebody who want to try to add a "disable Boost" option. 8)

Beauty

27-03-2012 16:38:35

Again I spent some hours for improvements.
tafkag, please check if the boost problem is solved now (when you use option "-noboost").

Changelog:

* New option "-noboost"
..... * Removes boost directory from the PATH system environment variable
..... * More directory ignores can be done by ModifyEnvironmentPath()
* If started from Visual Studio, the current path and used arguments are printed (good for debugging)
* Added check for config file option. If not exists, now there comes "useful" exception message.
* Ogre feature list will be printed at the end of the build process
..... (The output will be catched from somewhere in the thousands of output lines)


* Bugfix for the Oger version check
..... Even when version grabbing fails, the if-check always returned true.
..... So there was no exception. Instead the assemby version info file got an invalide entry.
* The Ogre/Mogre version will be printed
* Highlight of all warning messages (yellow)
..... All messages of worker processes will be analysed. If they contain special phrases,
..... the OutputManager will get a Warning() nofication.
* Show a SUCCESS message, when the Mogre build seems to be successful. (no exception happened)

Beauty

29-03-2012 00:10:44

Problems with Boost deactivation by PATH modification

* New option "-noboost"
..... * Removes boost directory from the PATH system environment variable
..... * More directory ignores can be done by ModifyEnvironmentPath()

Bad news:
I think my addition will not modify the path of the worker processes.

The path modifications will only be applied when the Process.UseShellExecute flag is true.
Details are here:
msdn...../library/system.diagnostics.processstartinfo.useshellexecute.aspx

Some lines below in the code I saw that Zarifus disabled this flag, because it caused a problem in the past.
Details related to this problem are here:
stackoverflow..../processstartinfo-hanging-on-waitforexit-why

If the problem doesn't happen with the CMake call, I can enable the flag (only) for the CMake process.
Zarifus, do you remember the behaviour of the CMake thread? Did it cause problems in the past?

Any idea what we can do?



I don't like to modify the "global" PATH environment variable instead.
Even if the MogreBuilder would restore the PATH variable (when MogreBuilder has finished)
it could cause problems.
When the MogreBuilder crashes or the shell window is closed while processing, then the restore can't be done.

Possible solution:
Start an independent process which is still alive when the MogreBuilder process is closed.
This process waits until the MogreBuilder is closed and then restore the PATH environment variable.
Additionally a copy of the unmodified PATH content can be stored as file.
(With an overwrite protection, for the case that MogreBuilder starts and the PATH wasn't restored yet.)

Well, the better solution would be to apply the modified PATH only to the worker process.
Or to find the right place in the CMake config files to disable boost.


By the way:
Currently I work on an addition to build the add-on MogreNewt.

Beauty

29-03-2012 00:35:51

Settings are loaded with the magic of reflection. [...]
What would you like to change?

Nothing. I just wondered how changes are applied.
When I right-clicked to a property to display all lines of usage, I couldn't see anything related.
It's realy an interesting way for "config files".

If I could see the rest of the function maybe I can help more?
I think the bug is fixed now. At least I could compile Ogre/Mogre after fixing the bug.
Someone in the Ogre chat explained me some details/behaviours of C++.
Additionally now I use an other way. More if-conditions (read-only) instead of variable modification.

I propose to update the depency files (related to Ogre/Mogre 1.7), upload a zip file of it to a custom Mogre download location and use this as default depency download for building Mogre 1.7.
Good proposal. Do you know how to do it?

Maybe there are also newer download files with updated Ogre depencies on the ogre3d website. (If the content is compatible to Mogre 1.7.)
Or we update the content of the current file manually. Then upload them as download file (NOT inside the repository) on BitBucket. Later MogreBuilder can download/extract them in the same way as it does now.

For CG it should be most easy. It contains only a few *.lib and *.h files. (The current version 2.2 is from October 2009!)
The other library directories contain source files.
I think there is a very good chance to find updated version of the on the Ogre website.
Or it's downloadable on the websites of the projects.

zarfius

29-03-2012 01:00:30

If the problem doesn't happen with the CMake call, I can enable the flag (only) for the CMake process.
Zarifus, do you remember the behaviour of the CMake thread? Did it cause problems in the past?

Any idea what we can do?

If I remember correctly the deadlock was mostly when the Hg tasks runs. You can try disable it for CMake and see what happens. The problem with deadlocks of course is that they only happens sometimes.

Or to find the right place in the CMake config files to disable boost.
This would be a much safer solution. There are are already methods in the code to modify config files and it should be relatively easy to implement once you know what to do.

It's realy an interesting way for "config files".
Yeh, it was quick and easy and makes it fairly painless to add new settings. Reflection is very powerful if you don't need real-time performance.

tafkag

29-03-2012 12:20:50

I don't have much time today, so just one quick note:

Or to find the right place in the CMake config files to disable boost.
This would be a much safer solution. There are are already methods in the code to modify config files and it should be relatively easy to implement once you know what to do.


I changed the command line options in OgreCMake.cs to


@"-D OGRE_CONFIG_ENABLE_PVRTC:BOOL=ON -D OGRE_CONFIG_CONTAINERS_USE_CUSTOM_ALLOCATOR:BOOL=OFF -D OGRE_USE_BOOST:BOOL=OFF -G ""Visual Studio 10"" ..\ogre",


and Ogre is building without boost, but building Mogre fails with


1>------ Build started: Project: Mogre, Configuration: Debug Win32 ------
1> MogrePrecompiledHeaders.cpp
1>c:\mogreautobuild\main\ogresrc\ogre\ogremain\include\threading\OgreThreadHeadersBoost.h(29): fatal error C1083: Cannot open include file: 'boost/thread/tss.hpp': No such file or directory
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


I tried setting "PrecompiledHeaders" to "Not Using Precompiled Headers" in the project settings, but the output is still the same and then I ran out of time.

Beauty

29-03-2012 18:51:59

Related Boost

Thanks for trying and reporting.

In my (successfully built) target directory I also have the file OgreThreadHeadersBoost.h.
It's content is just:

#ifndef __OgreThreadHeadersBoost_H__
#define __OgreThreadHeadersBoost_H__

#include <boost/thread/tss.hpp>
#include <boost/thread/recursive_mutex.hpp>
#include <boost/thread/condition.hpp>
#include <boost/thread/thread.hpp>
#include <boost/thread/shared_mutex.hpp>
#include <boost/thread/locks.hpp>

#endif


On my system it causes no problem with that.
The missing file tss.hpp doesn't exist in my target directory.

My idea:
When Boost is found in the PATH environment, the precompiler flag __OgreThreadHeadersBoost_H__ gets an other value.
Or the file OgreThreadHeadersBoost.h will not be included when Boost is disabled "globally".

Now I searched in all files:
Strange, there is no other file, which contains the String "__OgreThreadHeadersBoost_H__".
Can you search in all of your files, please?
Perhaps with Boost in the PATH there will be generated different files.

Now I searched in all files for the string "OgreThreadHeadersBoost.h".
It's was found only in these files:
Main\OgreSrc\ogre\OgreMain\include\Threading\OgreThreadHeaders.h
Main\OgreSrc\ogre\OgreMain\CMakeLists.txt


Content of OgreThreadHeaders.h:

#ifndef __OgreThreadHeaders_H__
#define __OgreThreadHeaders_H__

#if OGRE_THREAD_PROVIDER == 1
#include "OgreThreadHeadersBoost.h"
#elif OGRE_THREAD_PROVIDER == 2
#include "OgreThreadHeadersPoco.h"
#elif OGRE_THREAD_PROVIDER == 3
#include "OgreThreadHeadersTBB.h"
#endif

#endif


Related section in file CMakeLists.txt

if (OGRE_THREAD_PROVIDER EQUAL 0)
list(APPEND THREAD_HEADER_FILES
include/Threading/OgreThreadDefinesNone.h
include/Threading/OgreDefaultWorkQueueStandard.h
)
set(THREAD_SOURCE_FILES
src/Threading/OgreDefaultWorkQueueStandard.cpp
)
elseif (OGRE_THREAD_PROVIDER EQUAL 1) <--- CONDITION
list(APPEND THREAD_HEADER_FILES
include/Threading/OgreThreadDefinesBoost.h
include/Threading/OgreThreadHeadersBoost.h <--- INCLUDED HERE
include/Threading/OgreDefaultWorkQueueStandard.h
)
set(THREAD_SOURCE_FILES
src/Threading/OgreDefaultWorkQueueStandard.cpp
)
// ...




By the way:
Do you realy have Boost in your PATH environment variable?
If yes, can you temporarily remove it? (To be shure if this is the real reason.)

I hope I could help a little bit.

Beauty

30-03-2012 02:18:47

Changelog


* Started support for MogreNewt add-on

* new option: "-mogrenewt"
..... * Tries to build the MogreNewt add-on

* new option: "-onlyaddons"
..... * Skip the Ogre/Mogre build tasks.
..... * It's useful when Mogre is still build and only an add-on should be build

* Width of console window will be increased automatically
..... * Target width: 120 chars (about 1000 pixels)
..... * --> Better overview


* New class FileCopyTask
..... * This class simplifies to copy/move files
..... * Options:
.......... * Create backup of previous files in the target directory
.......... * Copy/move only specific files (by patterns, also multiple patterns are possible, e.g. "*.cpp *.h")
.......... * Clear target directory before copy/move files to there (to avoid conflicts, specific delete settings are available)
.......... * Dots can be printed while processing (1 dot per file)
..... * Can be used as class instance (good for task lists) or by calling a static method (good for single task)
..... * Counter for processed files


* Created a partial class of InputManager
..... * Default values are moved to "InputManager.Defaults.cs"

* Some more status information is printed

* Created method InputManager.GeneratePathVariables()
..... A place for value updates of path variables (e.g. combine parts of a directory structure)


Now I'm away for about 10 days.
I continue my work when I'm back.

Nevertheless also others are allowed to do further changes. (e.g. bugfixing)
If somebody needs access, please write me a private forum message with your e-mail-address.

zarfius

30-03-2012 12:29:59

Now I'm away for about 10 days.
I continue my work when I'm back.

Great job. Enjoy your time off :)

Beauty

03-04-2012 16:48:24

Just a short information:

Today I looked to the Bitbucket account of Sinbad (the father of Ogre).
He has a repository called "ogre-1.7-backports".
It seems so, that the aim of this fork is to have an Ogre 1.7 version, which includes some Ogre 1.8 features.
This could be interesting for everybody, who wants to stay with Mogre 1.7 for a while.
https://bitbucket.org/sinbad/ogre-1.7-backports

Next week I want to use this URL as input for the MogreBuilder.
I will report, if it works sucessful. (I suppose it will.)

Beauty

10-04-2012 17:48:52

Changelog


Restructuring: Moved files to directories "Managers" and "Helpers" for better overview


Advanced exception handling
..... * If an exception occurs, the stack trace will be printed
........ --> useful information for bug reports
..... * New argument "-development" --> disable exception catching
........ --> useful for debugging inside of Visual Studio


* FileCopyTask:
..... * bugfix: Wrong processing for file pattern definitions
..... * new method: RemoveWriteProtection()
..... * Print more information of file copy tasks

* MogreNewt add-on:
..... * Tiny changes
..... * Status: Grabbing all needed files (headers, etc.) seems to be fine (-:

zarfius

11-04-2012 01:13:37

..... * New argument "-development" --> disable exception catching
If I understand what you mean, Visual Studio has an option to do this already.
1. Click on the Debug Menu
2. Click Exceptions...
3. Check the "Thrown" checkbox for Common Languange Runtime Exceptions

This allows Visual Studios debugger to break on the line that throws an exception without the need to change your try catch code.

Beauty

11-04-2012 10:00:16

Thanks Zarifus,

I searched in Visual Studio and by Google for this feature, but couldn't find it. (Although it seems so apparently now.)
As consequence I will revert my changes in this case to keep the code more clear.

Beauty

12-04-2012 16:35:42

Changelog


* Improved config file processing
..... * Added support for comments after a line of code (before it caused problems)
..... * Example: myVar = "my value"; // my description
..... --> Good for config file documentation
* Bugfix: Crash at update of Mogre version

Encarmine

12-04-2012 17:46:43

Changelog
* Bugfix: Crash at update of Mogre version

Hey, you updated it 10 mins after I encountered this error =) Thx, moving on now.

Beauty

12-04-2012 17:57:04

The MogreBuilder creates the symbol file Mogre.pdb.
Unfortunately it seems so that it doesn't contain information about the unmanaged C++ code.

I need to debug the Ogre C++ code.
Has anybody an idea how to change the Mogre build settings?

If I remember right, the Mogre.pdb file of the Cygon build contains the "extended" information.
So perhaps it's possible to look for the related build configuration somewhere there.

Beauty

12-04-2012 18:05:02

Hi Encarmine

welcome to our Mogre community.
Did you still played around with Mogre or building Mogre yourself your first step.

Do you know the Mogre wiki page?
If not - have a look to it. It contains many useful links (tutorials, further information, etc.)
http://www.ogre3d.org/wiki/index.php/MOGRE

Hey, you updated it 10 mins after I encountered this error =)
Very funny. :lol:

It would be good to test everything before I upload changes.
But it takes much time to perform the whole process. So partially I just skip the depth testing.

Please give feedback of your building results. (successful? problems?)

Beauty

12-04-2012 21:49:50

About how to Include Debug information

Cygon sent me useful information by e-mail.
Here is my english translation (including some text highlighting):


I didn't use CMake for my builds.
Maybe with CMake the debug information isn't enabled.

Important settings in Visual Studio:

  1. C/C++ \ General \ Debug Information Format - should use of of the "Program Database" options (/Zi or /ZI)[/*:m][/list:u]

    DLL related:
    1. Linker \ Debugging \ Generate Debug Info - enable it (/DEBUG)[/*:m]
    2. Linker \ Debugging \ Generate Program Database File - The default value
      "$(TargetDir)$(TargetName).pdb" is useful.[/*:m][/list:u]

      Static library related:
      1. C/C++ \ Output Files \ Program Database File Name - Set to "$(TargetDir)$(TargetName).pdb" - then the linker combines the debug information of the .lib file with that of the .dll or .exe one[/*:m][/list:u]

        Related to the PDB files, I think it works like this:
        In the compiled .dll or .exe file is stored the absolute path to the .pdb file.
        The debugger try to locate it at this path or alternatively in the directory with the .dll or .exe file.

        At debugging look to the messages of the output window (Ctrl+Alt+O).
        Perhaps there is information about finding the debug information.

        Bad case:
        'Mogre.dll': Loaded 'X:\Y\Mogre.dll', Cannot find or open the PDB file

        Good case:
        'Mogre.dll': Loaded 'X:\Y\Mogre.dll', Symbols loaded


I will try to find out where/how to apply these options.
If somebody knows more, please tell me.



The Mogre build process contains 3 build steps:
* Ogre without Mogre linking
* Mogre
* Ogre with Mogre linking

Does I have to apply these settings to all build processes?



What's your suggestion how to apply the changes?
* To the CMake files, which generates the VS solution files?
* Or modify the autogenerated VS files?

I suppose first one is the better case ... If we know how to do. (I have no knowledge about CMake.)


Will it slowdown the Mogre application when the used binaries were build with extended debugging information?
(Perhaps it creates overhead. Or it disturbs code optimisations (at runtime) for the release build of the application which uses Mogre.)

In this case it would be good to have a switch in the MogreBuilder to enable/disable debug information.

zarfius

12-04-2012 23:32:26

Will it slowdown the Mogre application when the used binaries were build with extended debugging information?
(Perhaps it creates overhead. Or it disturbs code optimisations (at runtime) for the release build of the application which uses Mogre.)

I'm not sure how much it slows down the build proess but I suspect it will a little. I think the bigger overhead is the size of the resulting pdb files, they are normally pretty large.

Beauty

13-04-2012 00:09:44

I'm not sure how much it slows down the build proess
I mean the speed of the application, which uses the compiled Mogre library.

Beauty

13-04-2012 00:32:15

related to CMake + debug option

I searched a little bit for enable debug options by CMake.
There is so much information, a little bit too much for me as beginner (with less time, because of my diploma thesis).

In the MogreBuilder target directory Main\OgreSrc\build\ I searched for the file cmake_install.cmake, which seems to contain several settings.
I was shocked, because there are 55 files with this name (and further options) in all subdirectories.
Perhaps the ones in the subdirectories inherit the settings of the parent directory one.
(Something like this I read in a CMake beginners guide, but I'm not shure if it's also related to this file type.)


enable debugging symbols
set(CMAKE_CXX_FLAGS "-g")

To tell the compiler to print warnings, add debugging symbols and profiling code add the following line to your CMakeLists.txt
set(CMAKE_CXX_FLAGS "-Wall -g -pg")

-Wall specifies the warning level
-g enables debugging
-pg profiling


What happens if somewhere some flags were set and then I call set(CMAKE_CXX_FLAGS "-g") with just the -g flag?
Will it "kill" all other flags, which I set before?
Or will the flag be added to the other ones?

What's the difference between CMAKE_C_FLAGS and CMAKE_CXX_FLAGS ?
I saw both versions (with/without "XX").


An other useful post:
Adding a debug switch with CMake


Perhaps there is an interesting section in the CMake FAQ.
How can I build multiple modes without switching
It's about how to build Debug and Release in one shot, which is perhaps useful for a MogreBuilder option.


Ok, this is my research result of this night.
I'm not shure if I follow CMake more.
Perhaps I just try to change the settings of the generated VS files.
I need a quick solution to debug my modified (bugfixed) Mogre build, because I need it for my diploma thesis and my remaining time gets lesser and lesser.
Maybe I will idle my MogreBuilder development. My diploma thesis has high priority.

zarfius

13-04-2012 06:29:21

I'm not sure how much it slows down the build proess
I mean the speed of the application, which uses the compiled Mogre library.

Oh right, well in that case I don't think it makes a difference. The pdb file is used for debugging information when your running your application from within Visual Studio. If you run the application outside Visual Studio it won't make any difference, and of course you do not need to ship the pdb files with binaries.

Encarmine

13-04-2012 11:16:11

Please give feedback of your building results. (successful? problems?)

With updated MogreBuilder I built it successfully.

Beauty

13-04-2012 11:53:38

About CMake + Disable Terrain/Paging/Boost

I made some changes to the autogenerated VS files to enable better debugging.
Now while the build process works, I looked for CMake again.

Here I found an wiki page about Ogre options by CMake
Building Ogre with CMake

Related to the terrain/paging component:
  1. OGRE_BUILD_COMPONENT_PAGING - If enabled, Ogre's optional paging component will be built.[/*:m]
  2. OGRE_BUILD_COMPONENT_TERRAIN - If enabled, Ogre's optional paging terrain component will be built. [/*:m][/list:u]

    Then I searched for them in the MogreBuilder target directory.
    It seems so that the switch have to be set in the file Main\OgreSrc\ogre\CMakeLists.txt
    option(OGRE_BUILD_COMPONENT_PAGING "Build Paging component" TRUE)

    The flag is also set in the file Main\OgreSrc\build\CMakeCache.txt
    OGRE_BUILD_COMPONENT_PAGING:BOOL=ON

    I'm not shure how to apply a disable option of the MogreBuilder.
    1) To CMakeLists.txt
    2) To CMakeCache.txt
    3) To both
    Perhaps it depends if it's the first run or a re-run.


    I suppose the file CMakeLists.txt is also an important place to enable/disable Boost. (or to disable the autodetection?)

    Here are the related entries:
    cmake_dependent_option(OGRE_BUILD_COMPONENT_PROPERTY "Build Property component" TRUE "Boost_FOUND" FALSE)
    cmake_dependent_option(OGRE_USE_BOOST "Use Boost extensions" TRUE "Boost_FOUND" FALSE)


    The file CMakeCache.txt (seems to be autogenerated) contains several options or switches related to Boost.
    I suppose the CMakeLists.txt file is the correct way to enable/disable it.

    Important:
    What happens if CMake runs twice?
    Will it re-generate the file CMakeCache.txt?
    If not, changed settings of the file CMakeLists.txt would have no effect. (This is my assumption. Maybe there is a CMake flag to force re-generation.)


    Ok, 2 minutes ago my Mogre build got ready.
    Good time to commit this post and to continue my own work. :wink:

zarfius

13-04-2012 14:04:10

I don't know much about how CMake works either but this information looks very promising :) I guess one way to find out is to try it.
My guess is that you'll only have to change CMakeLists.txt and the CMakeCache.txt file will be autogenerated during the build.

What happens if CMake runs twice?
Will it re-generate the file CMakeCache.txt?
If not, changed settings of the file CMakeLists.txt would have no effect. (This is my assumption. Maybe there is a CMake flag to force re-generation.)

It might regenerate the cache if it detects that the original configuration has has changed, or maybe it will always use the cache if it exists. If my previous assumptions are true, maybe a simple method is to just delete the cache at the start of the build.

Here are some interesting bits from the CMake documentation: http://www.cmake.org/cmake/help/runningcmake.html

The first time CMake is run, it produces a CMakeCache.txt file...
After CMake has been run, and created a CMakeCache.txt file - you may edit it...
CMake will not alter an existing entry in the cache file itself. If your CMakeLists.txt files change significantly, you will need to remove the relevant entries from the cache file. If you have not already hand-edited the cache file, you could just delete it before re-running CMake.

Beauty

13-04-2012 15:43:38

How to build the debug version

Ok, 2 minutes ago my Mogre build got ready.
Bad result.
The size of the binary files and the PDB file did not change.
The file OgreMain.pdb wasn't generated.

The compilation I created with the MogreBuilder (called with the new option "-skipcmake").
But the modified settings are not applied.

...

By looking to the build task classes of the MogreBuilder I found the correct solution:
I just have to change the parameter BuildConfiguration in the MogreBuilder config file from "Release" to "Debug".
Then the debug versions will all needed PDB files will be generated.
It's so simple ...

Additionally I had to edit the file plugins.cfg, because the plugin dll files now have "_d" in the file name.
Without adjustment the plugin names you just get an exception without a notice for the real reason.

Now (with the Ogre debug version) I could find out the problem of my Ogre TSM bugfix. :D

By the way - the FPS rate of my application got extremely slow with the debug binaries.

Beauty

13-04-2012 21:28:47

I'm so happy!!
The deadlock causing Ogre bug is fixed correctly now.
Also I could manage to build MogreNewt against the Mogre build.
My Mogre application seems to work fine with my latest binaries.

Finally, now I can continue with the work of my diploma thesis. :D

By the way:
The Ogre bug was the main reason, why I started to improve the MogreBuilder.

zarfius

14-04-2012 10:52:20

I'm so happy!!
The deadlock causing Ogre bug is fixed correctly now.
Also I could manage to build MogreNewt against the Mogre build.
My Mogre application seems to work fine with my latest binaries.

Finally, now I can continue with the work of my diploma thesis. :D

By the way:
The Ogre bug was the main reason, why I started to improve the MogreBuilder.

Congratulations, you did some great work along the way too.

Its normal for the fps to be a lot lower in debug mode. That's the price you pay for the ability to debug. It also happens in normal c++ ogre.

Beauty

14-04-2012 13:12:05

Strange thing:
The Cygon builds contain several PDB files by which it's possible to debug the Ogre source code.
Nevertheless I didn't recognise a significant FPS decrease.
Especially not as dramatically as with the debug builds of the MogreBuilder. (I think the FPS rate fell from 150 to 15.)

So I think it would be useful to figure out how Cygon applies his compile settings.
(He didn't use CMake. Perhaps he created his projects from the scratch, added the sources and applied the settings in VS.)


MOIS
We should extend the MogreBuilder to build MOIS.
The depency OIS.dll will still be created by building Ogre.
OIS is the defaut input library of Ogre and I think it's important to include it.
The MOIS source code is in the Add-ons repository.
Good thing: By my (half finished) MogreNewt addition the MogreBuilder is able to clone the Mogre Add-ons repository.
So in general we "just" need to create a build task.

Beauty

14-04-2012 13:50:18

Related MOIS again.

I looked to the MOIS source code.
It doesn't link to an OIS.dll file (like compiled by the Ogre build task).
The OIS source code is included to the Mogre-Addons repository.

In the OIS code I see that it's version 1.2.0
The current version on the OIS project website is 1.3.
So if somebody like, he can update the code in Mogre-Addons repository. (Only the Windows related code is interesting for us.)

Beauty

14-04-2012 21:38:54

Building Ogre, Depencies, CMake, Options

I found an very interesting file in the Ogre source code:
Main\OgreSrc\ogre\BuildingOgre.txt

The latest version you find here:
https://bitbucket.org/sinbad/ogre/src/9 ... ngOgre.txt

Here is most of it's content.
I removed parts, which are not interesting for our MogreBuilder, e.g. Linux/iPhone notes.
Also I highlighted some lines.



GUIDE TO BUILDING OGRE
========================================================================

Ogre uses CMake as its build system on all supported platforms. This
guide will explain to you how to use CMake to build Ogre from source.


1. What is CMake?
-------------------

CMake is a cross-platform build system - or perhaps more accurately a
build configurator. It is a program which, from a set of CMake scripts,
creates a native build system for your platform that allows you to
build Ogre.
The build process is configurable via CMake. Ogre provides several
options which you can use to customise your build.


2. Getting CMake
------------------
[...]




3. Getting dependencies
-------------------------

Ogre requires the freetype library, but there are other dependencies we
strongly recommend you to use unless you know what you are doing. You
can get source or binary packages for each from their respective websites
listed below. We also offer precompiled dependencies or bundled source
packages for certain platforms, please refer to our download page:
http://www.ogre3d.org/download/source
[...]

Required dependencies:
* freetype: http://www.freetype.org

Recommended dependencies:
* Boost: http://www.boost.org (+)
* Cg: http://developer.nvidia.com/object/cg_toolkit.html
* DirectX SDK: http://msdn.microsoft.com/en-us/directx/
* FreeImage: http://freeimage.sourceforge.net
* zlib: http://www.zlib.net
* zziplib: http://zziplib.sourceforge.net

Optional dependencies:
* CppUnit: http://cppunit.sourceforge.net
* Doxygen: http://doxygen.org
* OIS: http://sourceforge.net/projects/wgois
* POCO: http://pocoproject.org (+)
* TBB: http://www.threadingbuildingblocks.org (+)

(+) Boost is used to build threaded versions of Ogre. Only the
boost-thread and boost-date-time libraries are required.
For Visual C++
you can find binary installers at http://www.boostpro.com.
Alternatively, you can use either POCO or TBB instead of Boost to
enable thread support in Ogre.



4. Preparing the build environment
------------------------------------

You should now create a build directory for Ogre somewhere outside
Ogre's sources. This is the directory where CMake will create the
build system for your chosen platform and compiler, and this is also
where the Ogre libraries will be compiled. This way, the Ogre source
dir stays clean, and you can have multiple build directories all
working from the same Ogre source.
If you are on Windows, you should now gather all the compiled
dependencies in a common directory called 'Dependencies'. Inside
this directory you should have the subdirectories bin, lib and include
where you place .dll, .lib and header files
of the dependencies,
respectively. (If you are using one of our precompiled binary packages,
then this layout will already have been created for you.)
This 'Dependencies' dir can then be placed either inside the Ogre
source directory or inside your chosen build directory. You can also
put it somewhere else, but you will then need to tell CMake the location
as described below.



5. Running CMake
------------------

Now start the program cmake-gui by either typing the name in a console
or selecting it from the start menu. In the field 'Where is the source
code' enter the path to the Ogre source directory (the directory which
contains this file). In the field 'Where to build the binaries' enter
the path to the build directory you created in step 4.
Hit 'Configure'. A dialog will appear asking you to select a generator.
Choose the appropriate one for your platform and compiler.
[...] for Visual Studio select the appropriate version and platform (Win32 | Win64); [...]
Click 'Finish'. CMake will now gather some information about your
build environment and try to locate the dependencies (+). It will then show
a list of build options. You can adjust the settings to your liking;
for
example unchecking any of the OGRE_BUILD_XXX options will disable that
particular component from being built. Once you are satisfied, hit
'Configure' again and then click on 'Generate'.
CMake will then create
the build system for you.

(+) If you receive errors about dependencies not being found, even though
you have successfully installed or compiled them in step 3, then you may
need to tell CMake where to look. [...]
If you followed the advice of step 4 and put all dependencies
in a common directory, then you can specify that directory in the
variable OGRE_DEPENDENCIES_DIR. Otherwise, you can specify the directory
for each dependency individually. Click on 'Add entry' to add a new CMake
variable, then select 'PATH' as the type. The name of the variable is
XXX_HOME, where XXX is to be replaced by the dependency package, e. g.
ZLIB_HOME, ZZIP_HOME or FREETYPE_HOME. For the value, specify the directory
where the dependency can be found and click Ok. Once you are done, hit
'Configure' again.

A GUI for CMake options?
Sounds interesting.

For our MogreBuilder it would be useful to know how to hit into the gap.
In other words do these steps:
  1. Let CMake gather build environment information and look for depencies.[/*:m]
  2. Apply the MogreBuilder settings by changing the OGRE_BUILD_XXX options.[/*:m]
  3. Let CMake generate the Visual Studio files.[/*:m][/list:u]

    Who has CMake experience and tell us how to perform these steps?
    I suppose we just need some magic command-line options for both CMake calls.



    6. Building Ogre
    ------------------

    [...]
    If you have doxygen installed and CMake picked it up, then there will
    be an additional build target called doc which you can optionally build.
    This will freshly generate the API documentation for Ogre's classes from
    the header files. In Visual Studio, just select and build the target
    'DOC'

    [...]

    Question:
    Is this "Ogre internal generated" documentation needed as base for the Mogre XML commentation tool?


    7. Installing Ogre
    --------------------

    Once the build is complete, you can optionally have the build system
    copy the built libraries and headers to a clean location. This location
    will strongly resemble the layout of our prebuilt Ogre SDKs. We recommend
    you do this step as it will make it easier to use Ogre in your projects.
    In Visual Studio, just select and build the target 'INSTALL'. This will
    create the folder 'sdk' inside your build directory and copy all the
    required libraries there.
    [...]


    Well, to create this post I needed one our.
    But I think it's a good investition of time.

Beauty

15-04-2012 00:51:33

MOIS

I had a go at adding MOIS to MogreBuilder tonight. It wasn't particularly difficult but I had to make a small change to the MOIS project in the MogreAddons repository and I don't have access to commit my changes. The screenshot above shows the minimum required steps to build MOIS. However, before it's finished a little more work needs to be done to be able to control exactly what is built each time you run MogreBuilder otherwise it will build Mogre as well which takes a long time.


I scrolled through all of the many posts and fond this one.
Nice to see that you still put efforts to build MOIS.

Now you have write access to the add-ons repository and can commit your changes.

Unfortunately you didn't uploaded your task file for building MOIS. It would be nice if you do so.
Then I try to finish the MOIS support.

otherwise it will build Mogre as well which takes a long time.
By the command-line parameter "-onlyaddons" you can disable the Ogre/Mogre build process.

Beauty

15-04-2012 02:59:45

Option documentation
I just wanted to add a tiny task to the "issue tracker", but then I wrote so much, that it's useful to post it in the forum, too:


--------
The MogreBuilder has some command-line options, but currently they are only visible in the source code.

Task:
Create documentation, which will be printed when MogreBuilder is called without arguments.
  1. General syntax[/*:m]
  2. Details about each options[/*:m][/list:u]

    Idea:
    Create a class for saving option details:
    1. Name (e.g. "-mogrenewt")[/*:m]
    2. Amount of needed arguments[/*:m]
    3. Description[/*:m][/list:u]

      Benifits of such a class:
      1. Processing and documentation at one place[/*:m]
      2. An "option description file" file can be generated, which is used by a GUI config application. So the GUI app knows, which options are available, by which arguments they will be applied and to embedd help information to the GUI.[/*:m]
      3. Creation of further options could be more clear than now.[/*:m][/list:u]

zarfius

15-04-2012 11:04:22

Unfortunately you didn't uploaded your task file for building MOIS. It would be nice if you do so.
Then I try to finish the MOIS support.

I haven't had a chance to get back to this and you have made many changes to the repository since I last checked it out. I'd like to get my changes into the repository sometime but it will probably take a while to merge the changes in with the latest version and test it. The actual build task is very simple, it looks like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Mogre.Builder.Tasks
{
class BuildMoisTask : MsBuildTask
{
public BuildMoisTask(InputManager inputManager, IOutputManager outputManager, MsBuildManager msBuildMgr)
: base(inputManager, outputManager, msBuildMgr)
{
}

public override string ID { get { return "mois:build"; } }
public override string Name { get { return "Building MOIS"; } }
public override string Description { get { return "Builds MOIS addon."; } }

public override void Run()
{
msBuildManager.Build(inputManager.MoisSolutionFile, inputManager.BuildConfiguration, "Win32", "Rebuild");
}
}
}

Of course, the a new configuration option also needs to be added for the MOIS Solution file path, but that's easy enough.

Strange thing:
The Cygon builds contain several PDB files by which it's possible to debug the Ogre source code.
Nevertheless I didn't recognise a significant FPS decrease.
Especially not as dramatically as with the debug builds of the MogreBuilder. (I think the FPS rate fell from 150 to 15.)

I don't think the FPS drop is caused purely by the PDB files. It's just something different between the Debug and Release configurations. Cygon is pretty clever when it comes to these kinds of things, you should have read of his blog, he has some information about when he built Mogre. Also, I beleive his solution files have already been uploaded into the MogreBuilder repository.

Beauty

16-04-2012 00:05:33

PDB files for Release
I found an interesting option in Visual Studio:

Project settings --> Build
On this tab scroll down and you find the button "Extended ..."
When you click it, an extra window pops up.
There is a ComboBox with the name "debug information"
and the settings "None", "Full" and "PDB-only".

I suppose "PDB-only" could be the option, which Cygon choosed for his Release builds.

Here is a screenshot.
It's German only, but shows a little bit where to find the options.
On right side you see the popup window.

Beauty

16-04-2012 00:34:54

Changelog


* Depency binaries will be copied to the output directory now
..... TODO: Check if it works well for the "Debug" builds
..... Further notes are described as comment to file
..... "AssembleBinaryFiles" at line ~80

* Assembly info update:
..... * Removed ".*" and the 4th place, because by this a
..... random(?) number was created (e.g. "1.7.4.22757")
..... * Update of assembly description
..... Example: "Created by MogreBuilder on 2012-04-15"
..... * Update of "AssemblyConfigurationAttribute" --> Debug/Release


* Added method descriptions for Task.ModifyFile() methods

* Added IO error handling and path check to task "AssembleBinaryFiles"


Added XML commentation tool
..... TODO:
..... * Create task to build the tool
..... * Create task to run the tool on the generated Mogre files

Beauty

16-04-2012 00:48:21

Changelog


Added code for building MOIS (not ready to use)


Thanks, Zarifus :D

Beauty

17-04-2012 11:49:32

Binary output directory

I build everything for Release and Debug.
Before copying all binary files to the output directory bin\Release.NET4\ or bin\Debug.NET4\ I added a breakpoint and saved an overview of all generated binary files (*.dll, *.lib).
Then I checked if everything was copied to the output directory.
The output seems to be fine for both, release and debug. (after my last changes to the MogreBuilder)

Well, the depency of the depencies shouldn't be needed.
(They should be linked static. I don't remember that they were needed in the past.)

So I hope the binary output is "complete". (No file missing.)


For the debug build I recognised, that the PDB file names are only in lower-case.
Example:
Plugin_BSPSceneManager_d.dll
plugin_bspscenemanager_d.pdb

Note nice, but I suppose this shouldn't be a problem, because in general on Windows it doesn't cares.
Perhaps I write a tiny method to "rename" them. So that they become the same case-style as the DLL and LIB files.


By the way:
Do you know the blog entry related to the Mogre 1.7.3 "Cygon builds"?
It's vers interesting. We could include his improvements to our MogreBuilder, e.g. the improved way to create depencies.
http://blog.nuclex-games.com/2011/08/mogre-1-7-3/

Beauty

17-04-2012 12:03:07

related Boost

Hi tafkag,

You have problems with Boost.
I'm not shure how to disable, but I researched for that and posted useful information in the MogreBuilder topic.

Can you please make a test with the MogreBuilder?
When the crash happens, scroll up to the Ogre "Feature Summary", which will be created by CMake.
There look for the Boost flag. Is this option enabled or disabled?
This is a useful information for our (my?) further work.

I can't promise that I focus on the Boost problem. But I want to figure out how to apply Ogre settings inside of the MogreBuilder process.

Honestly I should concentrate to my diploma thesis.
On the other hand I have motivation to improve the MogreBuilder (although I don't need further changes for myself).
I try my best to support Mogre and its community.

Beauty

17-04-2012 22:34:26

Binary tests

For quick testing of the built Mogre binaries we could use the different Mogre samples.
An overview and some remarks I posted here:
viewtopic.php?p=98956#p98956

Just in the moment I found a directory in the Ogre source code called "Tests".
The test codes for the Ogre core (e.g. RenderSystem) and for terrain/paging components.
There are also CMake scripts. So it should be easy to compile them (for Ogre only).
Currently the will not processed by the MogreBuilder. (No VS files will be generated for that.)

On the other hand I'm not shure if it's useful to compile and maybe autowrap them.
Because the test code calls Ogre methods, not Mogre methods.

So I suppose the only way is to port the code to Mogre / C#.

I'm not shure if we realy need this for our wrapper, because the tests seem to be only important for modified Ogre sources. For Mogre we don't change the Ogre core code. We just use it. The detailed checks should be done by Ogre developers themself before they check in their code.

For us it's only important to see if the wrapped binaries works in general.
At least I wanted to mention on that test files.

tafkag

18-04-2012 11:39:32

Hi Beauty,

Can you please make a test with the MogreBuilder?
When the crash happens, scroll up to the Ogre "Feature Summary", which will be created by CMake.
There look for the Boost flag. Is this option enabled or disabled?


I started the build with the following command line options and without the little code change from my previous post to disable boost:


MogreBuilder C:\MogreAutoBuild -config Default.cfg -noboost


Ogre built fine with Boost being enabled, but Mogre is still failing with the same error.
Here is the command line output:


Building Mogre

Rebuilding Mogre_vs2010.................................
Cannot open include file: 'boost/thread/tss.hpp': No such file or directory

Failed to build Main\Mogre_vs2010.sln

Exception stack trace for debugging:
--------------------------------------------------------------------------
at Mogre.Builder.MsBuildManager.Build(String projectFile, String configuration, String platform, String[] targets) in
C:\Repos\MogreBuilder\Source\Managers\MsBuildManager.cs:line 40
at Mogre.Builder.MsBuildManager.Build(String projectFile, String configuration, String platform, String target) in C:
\Repos\MogreBuilder\Source\Managers\MsBuildManager.cs:line 47
at Mogre.Builder.Tasks.BuildMogre.Run() in C:\Repos\MogreBuilder\Source\Tasks\BuildMogre.cs:line 18
at Mogre.Builder.TaskManager.RunNow() in C:\Repos\MogreBuilder\Source\Managers\TaskManager.cs:line 139
at Mogre.Builder.TaskManager.Run() in C:\Repos\MogreBuilder\Source\Managers\TaskManager.cs:line 112------------------
--------------------------------------------------------




===================== Feature summary =====================

Building components:
+ Paging
+ Property
+ Terrain
+ RTShader System
+ RTShader System Core Shaders
+ RTShader System Extensions Shaders
Building plugins:
+ BSP scene manager
+ Cg program manager
+ Octree scene manager
+ Portal connected zone scene manager
+ Particle FX
Building rendersystems:
+ Direct3D 9
+ OpenGL
Building executables:
+ Samples
+ Tools
Building core features:
+ DDS image codec
+ PVRTC image codec
+ FreeImage codec
+ ZIP archives
Build type: dynamic
Threading support: background (boost)
Use double precision: disabled
Allocator type: nedmalloc (pooling)
STL containers use allocator: disabled
Strings use allocator: disabled
Memory tracker (debug): disabled
Memory tracker (release): disabled
Use new script compilers: enabled
Use Boost: enabled



===================== Repeat of all errors and warnings =====================

Running CMake on Ogre source tree
-- Could not locate POCO
-- Could not locate TBB
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could not locate CppUnit
-- The following OPTIONAL packages could NOT be located on your system.
send_errorC:/MogreAutoBuild/Main/OgreSrc/ogre/Dependencies/bin/debug/OIS_d.dll did not exist, can't install!
Autowrapping Ogre classes
Notice: Output directory `build\doxyxml' does not exist. I have created it for you.
Building Mogre
Cannot open include file: 'boost/thread/tss.hpp': No such file or directory
Failed to build Main\Mogre_vs2010.sln

Duration: 0 hours 22 minutes

Beauty

18-04-2012 17:54:40

Thanks for testing!

Currently my "-noboost" option doesn't work.
I created to modify the environment path for the process only. Later I recognised, that this change will only be applied to the process, when a special flag is set. But when this flag is set, there can be some problems. (As Zarifus had in the past.) I saved some links to related pages. Perhaps I can tweak it.

The second way would be to enable/disable it by the CMake config.

A last point would be to figure out, what's the problem, when Boost is enabled.
I looked to the related code and I'm shure, that for Boost usages files are missing (tss.hpp).
I don't know the reason. Maybe I find time to figure it out.
Perhaps the related source code has to be added "manually". Means to create a task do download it.
On your system Boost IS available (it seems so). In this case we either need to change the search path (somehow) or create a task to copy the needed files to the path, where CMake is currently pointed to.

Well, I will see.
If somebody find out more information, just tell it.

Meharin

19-04-2012 23:44:56

Thanks for futhering this Beauty!

Another feature request, if/when there's time for someone to do it: MParticleUniverse support:

http://voxel.dl.sourceforge.net/project/mpu/Building%20Particle%20Universe%20For%20Mogre.pdf

Beauty

20-04-2012 00:51:23

Support for Partice Universe Wrapper

It's a great documentation!!
I never read about this before.
Mytoyke published his wrapper code without any further comments.
So people in the forum were confused about how to use/compile it.

I will add this link to the related forum topic and the PU wrapper wiki page.
So it's useful for others, too.

It seems to be relatively easy. Maybe I try to create a task class for it in the future.
If you like to give it a try, just do it.
Create a new file in directory Source\Tasks. Look to BuildOgreTask.cs to see an example file.

The build call is just:
msBuildManager.Build(inputManager.MU_PATH_HERE, inputManager.BuildConfiguration, "Win32", "Rebuild");

More effort is needed to check if Boost is available. (This can be done like in file CheckEnvironment.cs)
Additionally it could be checked if the needed parts of Boost are available.

And (only once) you need to modify the paths of the VS project file of ParticleUniverse.

Oh, and you need the sources. I wrote a message to Tyler Grusendorf and asked him, if he allows to copy the code into the official Mogre Add-ons repository.
I'm not shure if it's based on the wrapper of mstoyke (published in the wiki) or an other one developed by Tyler.
We will see.

Meharin, if you need write access to the MogreBuilder repository, just tell me.

GaanDjin

20-04-2012 01:13:02

Hi Beauty,

I'm more than happy for anyone to use my code!

I wrote it from scratch and may have the occasional glitch. Also some of the deeper classes I haven't implemented. I'm not sure if I need to but if there's a demand I can be persuaded.

I'm glad there's interest!

Tyler

P.s. feel free to message me with any questions.

Beauty

20-04-2012 03:50:12

Particle Universe wrapper is in Add-ons Repository now

Oh, it took so much time.
It's 4:45 o'clock at night and I only want to go sleeping.

But now an important step is done:
I added the MParticleUniverse sources to the Mogre Add-ons repository.
Before I removed all files, which are not needed or would blow up the repository size.
Binary files are removed. Media files are available by download link. (I added notes to text files and *.URL files for easy downloads) User specific files I removed, too. The PDF documentation I also added just as "download link". (I uploaded it to the download section of the Add-ons repository.)

So the MogreBuilder has success to the sources now.
At least when the Addons cloning task is enabled.
Currently it can be done by a trick: Use the option "-mogrenewt" to enable add-ons cloning.
Later this will be improved by a specific PU command-line option.

Note: If the directory "MogreAddons" is already inside of your target directory, you need to update it manually. (or just delete it to get it cloned again)

Ok, my bed is waiting for me for more than 2 hours.
(Some time I wasted, because of my limited Mercurial knowledge. But I don't describe the reasons of my current trouble. I just want to sleep now.)

Over the weekend I'm offline.
See you next week.

Beauty

15-06-2012 19:26:11

MogreBuilder modification --> Build Ogre depencies

User Caprico (Andreas Schuster) cloned the MogreBuilder repository and made some changes.
The modified MogreBuilder clones (and build??) the depencies of Ogre developer Cabalistic.
I suppose these are the "latest official Depencies" for Ogre. (But I'm not shure.)


I changed MogreBuilder to build Ogre dependencies from https://bitbucket.org/cabalistic/ogredeps <-- Ogre depencies of Cabalistic

Please have a look at https://bitbucket.org/caprico/mogrebuil ... f6215abc7b <-- Modified MogreBuilder

The post was published here: https://bitbucket.org/mogre/mogrebuilde ... -depencies


My basic plan was to use the depencies of Cygon.
He updated them and compiled them with the same compiler version.
(Especially to update the depencies to build FreeImage was a little bit complex Cygon said.)
Cygon offers precompiled binaries of the depencies and the updated sources.
(I think the links I still pulished in this topic.)

I just looked to the code changes, but didn't test it.
If it works well (re-building the sources of the depencies by MogreBuilder??), we could pull the changes to our "official" repository.
Then I suppose there would be no need anymore to focus to the depencies Cygon.

Well, I didn't look to the depency sources of Cabalistic yet.
(Does Cabalistic only offers code or also precompiled binaries?)

If anybody is interested, he can have a look to both: Capricos MogreBuilder updates and the depencies.
Or just try to build and test Mogre with Capricos MogreBuilder code.
Feel free to publish more information if you found out something interesting.

Currently I have no free-time, because of my diploma thesis.
When I finished my university study I want to continue my MogreBuilder work.

Caprico

17-06-2012 14:22:47

Finally I found the time to register on the forum myself and add some words to Beauty's explanations about my changes in MogreBuilder.

My intention was to get the dependencies from a official repository and build them with MogreBuilder. So we don't have to maintain another dependency package or wait for it to be updated. Fortunately Ogre doesn't differentiate between dependencies for Ogre 1.7 or 1.8. The dependencies in the repository still work fine for Mogre 1.7.

I added a task to clone Cabalistic's repository. Furthermore I changed the OgreCmake task to run CMake twice. The second time it runs it integrates the dependencies into Ogre's build process. We don't need another task to build them explicitly.

Feel free to try it out for yourself. If you want I can send a pull request.

Please note: MogreBuilder displays some error messages about missing dependencies. They result from the first time CMake runs. The second time it runs it finds the dependencies folder and doesn't show errors anymore. Maybe I can hide these error messages later.

Beauty

17-06-2012 18:02:55

Caprico, thank you very much for your improvements and your forum post.

The way how you integrated the "official" depencies (by source building) is sweet. Additionally I'm surprised how easy it can be with pre-configured CMake settings.
Now I found the information of user Cygon, who had some trouble to compile them (especially FreeImage). For details look here:
http://blog.nuclex-games.com/2011/08/mogre-1-7-3

MogreBuilder displays some error messages about missing dependencies. They result from the first time CMake runs.
Uses your first CMake run the current state of the official MogreBuilder repository or did you already modify something for the first run.
In general the current version works fine.
... with only one exception: One user has trouble with Boost. Somehow the CMake processing enables the "Boost building flag", although it's disabled by default. I suppose it happens when CMake finds an installed Boost on the computer. Unfortunately we didn't find a way yet how to solve the problem. (e.g. by forcing to disable Boost) Details about this problem were posted in this (long) forum topic.


Maybe I can hide these error messages later.
I already added some code to filter messages. (To apply an other colour or to eliminate messages.)
The code to eleminate messages you find in file Source\Managers\Task.cs.
Search for the commentation string //-- reduce useless information when patch failed --. The lines below (number 81 .. 88) show you how to filter messages.
For the case that the messages are in red colour, then they are grabbed by the ErrorDataReceived event handler. In this case you need to add a similar filter to the related callback method (~ line 133).
I hope you understand what I mean. To extend the message filter needs lesser time than writing this post. :wink:

Currently I don't touch the code, because of my diploma thesis.

I gave you write access to the official MogreBuilder repository. So you can commit your improvements.
Please commit only code, which runs sucessfully on your computer. (create working Mogre binary files.)
Addidionally, please add full descriptions to your Mercurial commits if needed to understand the changes (or its background).

Beauty

18-06-2012 12:56:20

Here are more details about Capricos improvements.
(They were posted as answer to my questions in the MogreBuilder bugtracker (here))



Questions:

1) Does your modified MogreBuilder build the depencies from the sources?



1) Yes, dependencies are built from source





2) In file "AssembleBinaryFiles.cs" you removed the "warning message" (for debug builds) and its description.
Did you build Mogre with "debug" setting?
If yes - are you shure that all generated files are created in the correct build directory and copied to the output directory?



2) Dependency building is included in Ogre's build process itself, so the binaries are created and copied together with Ogre in the correct directories. No need to check for binaries in dependencies folder. And yes, I tested it with both Debug and Release builds.





3) You added OIS to the "BuildOgreTask.cs".
Does the MogreBuilder also build the MOIS wrapper?

Notes:
There is as well the file "BuildMoisTask", but currently it's not processed by the MogreBuilder.

The source code of MOIS is located in the MogreAddons repository. The MogreBuilder can still clone this repository.

I don't remember the option yet to clone the Add-ons repository. You could look how I applied the "-mogrenewt" option. It set the flag "inputManager.Option_MogreNewt". And in "TaskManager.cs" is check if an option was used, which needs to clone the Add-ons repository. In file "TaskManager.cs" search for the string "--- optional add-on tasks ---". There you see more.
Sorry that I can't support you by extending the code. I need to concentrate to my diploma thesis.



3) MOIS is not built by MogreBuilder (not yet, give me a few days more ;-) ). But OIS was included in the old dependency archive, so I added it too.

zarfius

18-06-2012 23:59:41

I'd just like to say I'm impressed by Capricos efforts :) Developers like him are what keep these projects moving. Thanks mate.

tafkag

24-06-2012 11:36:20

While my previous unsuccessful attempts took place on my working machine, the MogreBuilder just compiled Mogre successfully on my home machine. Just wanted to give some positive feeback... :)

Beauty

24-06-2012 14:37:27

Thanks for your feedback.
I'm happy to see that's working and additionally there is an interest. :D

Beauty

24-06-2012 19:21:02

I got following forum message from user Edoardo:


Hi beauty,

I attach you a patch that you might find useful to add in the Mogrebuilder project, it's just an update of the smiley80's MogreXML project, updated to Visual C# 2010 and .NET Framework 4.

Hoping to be useful,

best regards

P.S.: Let me know if you don't agree or if there are problems about something. And thanks for the mogrebuilder project!



# HG changeset patch
# User Edoardo Molinatti <e.molinatti@gmail.com>
# Date 1338048621 -7200
# Node ID c2f5b5c30c15855818e6d2a3dfb379495772fbcf
# Parent a174e15ddb336e4b208ef39d349681ff41de7e64
Updated MogreXml Tool from Visual C# 2008 to 2010, and TargetFramework from
.NET Framework 2.0 to .NET Framework 4.0; also noted the author 'smiley80'

diff --git a/Tools/XmlCommentationTool/MogreXml.csproj b/Tools/XmlCommentationTool/MogreXml.csproj
--- a/Tools/XmlCommentationTool/MogreXml.csproj
+++ b/Tools/XmlCommentationTool/MogreXml.csproj
@@ -1,4 +1,5 @@
-<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">;
+<?xml version="1.0" encoding="utf-8"?>
+<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">;
<PropertyGroup>
<ProjectGuid>{57C86F3A-E5C7-45B5-8D60-38C79D8713D5}</ProjectGuid>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
@@ -6,7 +7,7 @@
<OutputType>Exe</OutputType>
<RootNamespace>MogreXml</RootNamespace>
<AssemblyName>MogreXml</AssemblyName>
- <TargetFrameworkVersion>v2.0</TargetFrameworkVersion>
+ <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<AppDesignerFolder>Properties</AppDesignerFolder>
<SourceAnalysisOverrideSettingsFile>C:\Dokumente und Einstellungen\Tobias Bohnen\Anwendungsdaten\ICSharpCode/SharpDevelop3.0\Settings.SourceAnalysis</SourceAnalysisOverrideSettingsFile>
<AllowUnsafeBlocks>False</AllowUnsafeBlocks>
@@ -14,6 +15,11 @@
<WarningLevel>4</WarningLevel>
<TreatWarningsAsErrors>false</TreatWarningsAsErrors>
<StartArguments>.\Mogre.dll Ogre Mogre -d:.\xmlMogre\</StartArguments>
+ <FileUpgradeFlags>
+ </FileUpgradeFlags>
+ <UpgradeBackupLocation>
+ </UpgradeBackupLocation>
+ <OldToolsVersion>3.5</OldToolsVersion>
</PropertyGroup>
<PropertyGroup Condition=" '$(Platform)' == 'x86' ">
<PlatformTarget>x86</PlatformTarget>
diff --git a/Tools/XmlCommentationTool/MogreXml.sln b/Tools/XmlCommentationTool/MogreXml.sln
--- a/Tools/XmlCommentationTool/MogreXml.sln
+++ b/Tools/XmlCommentationTool/MogreXml.sln
@@ -1,7 +1,6 @@

-Microsoft Visual Studio Solution File, Format Version 10.00
-# Visual Studio 2008
-# SharpDevelop 3.1.1.5189
+Microsoft Visual Studio Solution File, Format Version 11.00
+# Visual C# Express 2010
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MogreXml", "MogreXml.csproj", "{57C86F3A-E5C7-45B5-8D60-38C79D8713D5}"
EndProject
Global
@@ -10,9 +9,12 @@
Release|x86 = Release|x86
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
+ {57C86F3A-E5C7-45B5-8D60-38C79D8713D5}.Debug|x86.ActiveCfg = Debug|x86
{57C86F3A-E5C7-45B5-8D60-38C79D8713D5}.Debug|x86.Build.0 = Debug|x86
- {57C86F3A-E5C7-45B5-8D60-38C79D8713D5}.Debug|x86.ActiveCfg = Debug|x86
+ {57C86F3A-E5C7-45B5-8D60-38C79D8713D5}.Release|x86.ActiveCfg = Release|x86
{57C86F3A-E5C7-45B5-8D60-38C79D8713D5}.Release|x86.Build.0 = Release|x86
- {57C86F3A-E5C7-45B5-8D60-38C79D8713D5}.Release|x86.ActiveCfg = Release|x86
+ EndGlobalSection
+ GlobalSection(SolutionProperties) = preSolution
+ HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
diff --git a/Tools/XmlCommentationTool/Properties/AssemblyInfo.cs b/Tools/XmlCommentationTool/Properties/AssemblyInfo.cs
--- a/Tools/XmlCommentationTool/Properties/AssemblyInfo.cs
+++ b/Tools/XmlCommentationTool/Properties/AssemblyInfo.cs
@@ -10,13 +10,15 @@
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("MogreXml")]
-[assembly: AssemblyDescription("")]
+[assembly: AssemblyDescription("Mogre Xml comments creator")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("MogreXml")]
-[assembly: AssemblyCopyright("Copyright 2009")]
+[assembly: AssemblyCopyright("© 2009 by 'smiley80'")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
+//[assembly: NeutralResourcesLanguage("en")] // "en-GB" "en-US"
+//[assembly: CLSCompliant(true)]

// This sets the default COM visibility of types in the assembly to invisible.
// If you need to expose a type to COM, use [ComVisible(true)] on that type.


Currently I don't know how to include patches and have no time to discover out how to do.
Perhaps someone else wants to do the job?
Additionally I offer Edoardo to get write access to the repository. So he can include it by its own.

I'm happy to see that there are also other developers, who support our work with MogreBuilder. :D

Beauty

24-06-2012 21:13:22

If somebody has knowledge about the usage of Mercurial on command-line,
have a look to the task #17 Repository improvements (check + update) in the issue tracker.
Even if you don't have time for programming, some notes about the needed commands are useful.

Beauty

24-06-2012 23:36:51

low priority problems with CMake
--------------------------------------------------------------

Oh dear, in general I didn't want to touch the MogreBuilder until I finished my diploma thesis.
Motivated by improvements of others I wanted to add/change tiny things. But now I spend some hours again. (searching in code, writing in issue tracker, coding)

My last run seems to be successful, but I saw a strange CMake error related to "freetype".
I suppose it's in relation with building the Ogre depencies.

Additionally there is a message about a non existing OIS.dll file.
The file was built (as I see in the binary output directory). Maybe a path is wrong and CMake searches on the wrong place.
If everything is correct with CMake, then OIS should be listed in the Feature Summary.

Here is a screenshot of the error messages:


I don't thing it's a big problem (because the OIS.dll file build somehow), but I wanted to mention it.

P.S.
After a second run of MogreBuilder (with output to the still existing directory) I get no error message related to FreeType.

update:
After running CMake twice (by the MogreBuilder) the file OIS.dll is not built.
So I suppose it's done somewhen later.
Additionally it seems so that it's not build in the directory where CMake searches for it, because this directory doesn't exist after the whole MogreBuilder build process.
<MogreBuilder_TargetDirectory> / Main / OgreSrc / ogre / Dependencies / src / bin / release / OIS.dll

zarfius

25-06-2012 00:07:34

I'm happy to see that there are also other developers, who support our work with MogreBuilder. :D
It seems there are a few other developers helping for 2 reasons:
1. Because MogreBuilder is now the easiest way to build Mogre (pat on the back for that) :)
2. Mogre needs to be updated to match the new version of Ogre (v1.8 )

So, first let me say thankyou to the new developers helping out. Second, I think getting MogreBuilder to build Mogre v1.8 is our top priority task in this thread and anyone who has tried can I ask you to please post your experiences and problems so we can put together a task list.

Caprico

25-06-2012 21:48:24

My last run seems to be successful, but I saw a strange CMake error related to "freetype".
I suppose it's in relation with building the Ogre depencies.

Yes, it's related to building of the dependencies. Freetype can be found in the dependencies package. The first time CMake runs, it doesn't include this package. So CMake fails to find freetype and exits with an error. The second time CMake runs the dependency package is included, freetype and all other dependencies are found and CMake finishes without errors. That is why I wanted to hide the error messages from the first CMake run.

Additionally there is a message about a non existing OIS.dll file.
Ogredeps' cmake script seems to be a bit buggy. It is looking for OIS_d.dll even in release builds and fails to find OIS.dll too. Not building OIS at all should be the best solution, at least until MOIS is integrated into MogreBuilder.

Second, I think getting MogreBuilder to build Mogre v1.8 is our top priority task in this thread and anyone who has tried can I ask you to please post your experiences and problems so we can put together a task list.
I started to work on this. I already ported the ClrObject patch. It applies cleanly against the current Ogre 1.8 source but doesn't include any of the new classes in 1.8 yet. MogreBuilder still crashes sometime later in the build process. Didn't found the time to look into this further.
I uploaded the patch file here, in case somebody else wants to try too.

Beauty

03-07-2012 13:18:32

That is why I wanted to hide the error messages from the first CMake run.
I think instead of hiding everything of the first CMake run I think we could switch the error/waring highlighting to "normal colour". Then the user still can read the messages, but don't get confused. Additionally the errors/warnings would not be shown in the "error summary" at the end of the build process.
I would like to work on this task. But it needs time until my diploma thesis is finished. (I suppose in September.)

I uploaded the patch file here, in case somebody else wants to try too.
If it's useful, we could create a branch for building Ogre 1.8 in the MogreBuilder repository. Maybe this is a good way if more than one person try to update Mogre.

It applies cleanly against the current Ogre 1.8 source but doesn't include any of the new classes in 1.8 yet.
There is an XML file for the MogreBuilder configuration where you can exclude (and include?) classes for auto wrapping. More I can't tell you in the moment. But maybe this is a useful starting point for further research.
Unfortunately there is no documentation (nor forum posts which I have seen) about the Mogre wrapper configuration.

Caprico

03-07-2012 21:18:05

MogreBuilder now has Support for building MOIS

To build MOIS add "-mois" to the command line when you call MogreBuilder, for example:
MogreBuilder c:\myMogreBuild -config Default.cfg -mois
The resulting MOIS.dll will be copied to MogreBuilder's target folder (bin/Debug.NET4/ or bin/Release.NET4/), next to all other DLLs.

zarfius

03-07-2012 23:03:23

Great work Caprico. MOIS has been on the TODO list for a while. Thanks for crossing it off :)

The only thing I would have done differently is add an option to the config file rather than a command line switch. This allows a bit more control over the options (like the location of the MOIS repository for example) and makes it easier to setup different configuration files for different purposes.

I guess it doesn't make a whole lot of difference though, so I wouldn't bother changing it. The main thing is that it's done. :)

Beauty

04-07-2012 13:36:13

Thanks Caprico for completation of the MOIS support :D

about ways of configuration

add an option to the config file rather than a command line switch
I also thought about to add config switches to the config file. As result I think the current way is a good way.

All "important" configurations (e.g. repository URLs are in the config file.)
When we add support of switches for command-line AND config file, it would increase the maintain effort.
I think a better way is to keep the "base configuration" in the config file and enable/disable flags by command-line option.
On my computers I created *.bat files for different build settings. I think this is a good way.

In the future I want to use an additional GUI tool for building.
The MogreBuilder should save all possible options (including description) to an XML file. The GUI tool should read it and offers the user a graphical interface, including descriptions for the options. Related to this way of configuration I created the issue tracker entry #13 Add argument documentation.

In the past was a suggestion to put the GUI inside of the MogreBuilder. I think to have seperate tools would be better.

Well, that's my own opinion. If someone has an other opition, of course he can tell it.

Beauty

04-07-2012 13:47:46

This allows a bit more control over the options (like the location of the MOIS repository for example)
Don't worry about the MOIS URL. The official code is inside of the Mogre Add-ons repository. Cloning this repository is still done by the MogreBuilder (if needed for an option).
If someone wants to use his own MOIS sources, he the URL can already be changed in the config file.

tafkag

19-07-2012 17:42:37

I was finally able to build Mogre on my working machine. Basically, all I had to do was disable threading and boost in the cmake options. I changed the '-noboost' command line parameter to set these options in the cmake task class. I uploaded a patch, maybe someone with write-perissions wants to review it and push it to the repo.

Beauty

19-07-2012 20:22:27

I'm happy to hear that the build process on your work computer now could be performed successfully.
Also it's nice that you provide an improvement for the MogreBuilder.

I want to give you write access to the MogreBuilder repository.
For this send me your e-mail-Address by private message.

Everytime when you push code to the official repository, please be shure that it doesn't cause trouble.
The best would be to perform a full build process to a fresh target directory.
(Sometimes I made tiny changes which caused an exception. So it was a good idea to make a test build.)

Hint:
To avoid the long waiting time for downloading/cloning the Ogre and Mogre repository, you can point the URLs (in a seperate config file) to a local copy of them.
Then you MogreBuilder "downloads" them from your local harddrive. It's usable for test with empty target directories.

Example:

MogreRepository = @"C:\MogreBuilder\local_MogreRepository\";
OgreRepository = @"C:\MogreBuilder\local_OgreRepository\";
I'm not shure if needed, but you should add a backslash to the paths end.

Beauty

19-07-2012 21:01:29

Related to support of Ogre 1.8


I started to work on this. I already ported the ClrObject patch. It applies cleanly against the current Ogre 1.8 source but doesn't include any of the new classes in 1.8 yet. MogreBuilder still crashes sometime later in the build process. Didn't found the time to look into this further.
I uploaded the patch file here, in case somebody else wants to try too.


I think it's a good idea to create a second branch for Ogre 1.8 related improvements.
This is good for team orientated development and doesn't disturb the 1.7 build process.
When the 1.8 branch works stable/successful, we can merge it with the default branch.

Beauty

19-07-2012 21:19:31

Basically, all I had to do was disable threading and boost in the cmake options.

Now you are a little bit experienced with CMake options.
It would be nice if you try to figure out how to set the disable flags for the terrain and paging components.
Useful details (perhaps all you need to know) you find in these previous posts: here and here

If you have less time, you don't need to add command-line options. This can be done by others (like me).
Important is the knowledge HOW to apply the flags in the right way so that the MogreBuilder recognise it.

update:
Perhaps this could be the roadmap for applying Ogre options?

For our MogreBuilder it would be useful to know how to hit into the gap.
In other words do these steps:
  1. Let CMake gather build environment information and look for depencies.[/*:m]
  2. Apply the MogreBuilder settings by changing the OGRE_BUILD_XXX options.[/*:m]
  3. Let CMake generate the Visual Studio files.[/*:m][/list:u]

tafkag

23-07-2012 09:27:34

CMake options

Now you are a little bit experienced with CMake options.
It would be nice if you try to figure out how to set the disable flags for the terrain and paging components.


Disabling the terrain and paging components via cmake is pretty straight foward. You have to add
-DOGRE_BUILD_COMPONENT_PAGING:BOOL=FALSE -DOGRE_BUILD_COMPONENT_TERRAIN:BOOL=FALSE
to the cmakeArguments and disable the respective component in "BuildOgreTask.cs" and Ogre builds without it. I can make the code changes and add command line options to not build the components (-noterrain -nopaging ?).

So, building Ogre without terrain/paging is no problem, but without them Mogre doesn't build anymore. The terrain/paging classes are being wrapped by the auto-wrapper and if they are not built by Ogre, the Mogre build process crashes. I'm not quite sure what changes have to be made to the auto-wrapper to exclude the two components...

Beauty

23-07-2012 12:30:18

Thanks for your test and report.

The reason could be following:
In the file Codegen/AutoWrap/Attributes.xml are class settings for the autowrapper process. (Current revision here)
To disable terrain/paging I suppose it's needed to remove or comment out some entries of the XML file.

To figure out, which are the terrain/paging options we can search for related XML tags.
Additionally we could have a look to the other repository branch (called "Mogre17"), which doesn't contain terrain/paging support. (It's current Attributes.XML file you find here).

Maybe we can write a task for modifying that XML file.
More detailed:
If needed, a copy of the XML file will be generated, modified and used for autowrapping.

I think the modifyer way could better than to have different versions of the XML file, because then we would need all combinations of all available settings. If we add one more XML based setting, the possible amount of configurations would be the twice large amount.

One more idea:
To the XML file we could add "mark-ups" as comments, e.g. <!-- TerrainStart --> ... <!-- TerrainEnd -->. This way should be better to maintain in the long-term (than doing everything by explicite lines of code).

By the way:
Is there a sense to have an enabled paging component when the terrain component is disabled?

Well, I don't have time for writing a task now, but I'll keep it im mind. If nobody does it before, I want to code it after my diploma thesis.

Beauty

23-07-2012 12:41:44

tafkag, now you have write access to the MogreBuilder repository.
Have fun! :mrgreen:

It applies cleanly against the current Ogre 1.8 source but doesn't include any of the new classes in 1.8 yet.
Caprico, the settings for the new classes you can try to apply to the same XML files as refered in my last post:
Codegen/AutoWrap/Attributes.xml

I'm so sad that I currently have no free-time, because I have big motivation to improve the MogreBuilder.

zarfius

23-07-2012 13:35:56

Maybe we can write a task for modifying that XML file.
More detailed:
If needed, a copy of the XML file will be generated, modified and used for autowrapping.

I think this is a good idea, but I'm not sure if it's really required. From what I remember, the autowrapping code looks for the header files (.h) and uses them to determine what methods need to be wrapped. Since the Ogre terrain code is in a different directory, it might be possible to disable wrapping by excluding the terrain header files somehow. It's been a while since I looked at the code and I don't know how good my memory is, but I think it's at least worth investigating before going down the path of modifying the XML file.

mstoyke

23-07-2012 18:29:21

If I remember it correctly, I had to add the folder with the terrain and paging headers to the doxygen config file to include them in the wrapper generator. The changes I made to the XML file will be ignored if those headers are not parsed, so you can leave the XML file unchanged.

Beauty

24-07-2012 20:56:27

Good notes!

I'm very surprised and happy that mstoyke follows this topic. :D

I had to add [...] to the doxygen config file
It would be useful if you have a look to the code and tell us the name of the doxygen config file.

Beauty

26-07-2012 10:21:58

Disable Terrain/Paging components

I think I found the related file in the Mogre repository:
Codegen\cpp2java\ogre4j.doxygen

There are the following lines:

#---------------------------------------------------------------------------
# configuration options related to the input files
#---------------------------------------------------------------------------
INPUT = "../../Main/OgreSrc/ogre/Components/Terrain/include" \
"../../Main/OgreSrc/ogre/Components/Paging/include" \
"../../Main/OgreSrc/ogre/OgreMain/include" \
"../../Main/OgreSrc/ogre/OgreMain/include/WIN32" \
"../../Main/Ogre"

And additionally these:

#---------------------------------------------------------------------------
# Configuration options related to the preprocessor
#---------------------------------------------------------------------------
INCLUDE_FILE_PATTERNS =
PREDEFINED = WIN32 \
NDEBUG \
_USRDLL \
_MT \
OGRE_NONCLIENT_BUILD \
_OgrePagingExport \
_OgreTerrainExport


In the case that someone wants to disable terrain/paging, I suppose we have to do this:
  1. Apply the CMake flags[/*:m]
  2. Remove or comment out the paths in the doxygen file
    (Can be done in a similar way as suggested for the XML file in a previous post)[/*:m][/list:u]

    I'm not quite sure what changes have to be made to the auto-wrapper to exclude the two components...
    Now you know. Have fun. :mrgreen:

    It applies cleanly against the current Ogre 1.8 source but doesn't include any of the new classes in 1.8 yet.
    Can you tell us an example name for a new class?
    There is not much information in the Ogre 1.8 porting notes. (In the Ogre news the official maintainers wrote, that they want to publish a detailed list of changes later.)

Zonder

26-08-2012 17:59:07

Just a heads up the latest tortoise (tortoisehg-2.4.3-hg-2.3-x64) gave errors using the builder it was in the hg.exe for some reason?? but using the previous build all works ok (tortoisehg-2.0.5-hg-1.8.4-x64)

Beauty

26-08-2012 19:23:50

Thanks for your note.
Unfotunately I have to time for tests and searching the bug.
My TortoiseHG version is 2.4.2 (contains Mercurial 2.2.3).
I'm not shure, but I think I didn't update my TortoiseHG since my last Mogre build.
So maybe the problem caused by the switch from Mercurial 2.2 to 2.3.

It would be useful if somebody else updates TortoiseHG and checks if he also has a problem.
If so, I'll add a notice to the repository front page and the readme.txt file.


Disabling the terrain and paging components
Tafkag, did you do some further experiments to disable the components by editing the config file ogre4j.doxygen?

Zonder

26-08-2012 21:00:58

yeah possibly was the 2.2 -> 2.3

I'm now trying to figure out why cmake ain't working :roll:

"CMake Error: Could not create named generator Visual Studio 10"
anyone know? am still trying to figure whats not quite right

I rebuilt my pc so all fresh installs

Zonder

26-08-2012 21:16:15

nvm an uninstall reboot and reinstall of cmake seems to have stopped the error

Zonder

27-08-2012 14:38:46

I reinstalled the newer tortoise to get the error I recieved. (And to ensure it still happened after the cmake issue)

Tortoise it self does work though if I tell it to clone the folders created in the process so it's a little odd. Must be somthing to do with the exact command line been passed maybe. Then again older version works so easier to just install that :)

Other than the little external glitches the builder worked perfectly :lol:

===================== Repeat of all errors and warnings =====================

Checking out the source code of Mogre (please be patient)
** unknown exception encountered, please report by visiting
** http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 2.3)
** Extensions loaded:
Traceback (most recent call last):
File "hg", line 42, in <module>
File "mercurial\dispatch.pyo", line 28, in run
File "mercurial\dispatch.pyo", line 65, in dispatch
File "mercurial\dispatch.pyo", line 88, in _runcatch
File "mercurial\dispatch.pyo", line 740, in _dispatch
File "mercurial\dispatch.pyo", line 514, in runcommand
File "mercurial\dispatch.pyo", line 830, in _runcommand
File "mercurial\dispatch.pyo", line 801, in checkargs
File "mercurial\dispatch.pyo", line 737, in <lambda>
File "mercurial\util.pyo", line 472, in check
File "mercurial\commands.pyo", line 1206, in clone
File "mercurial\hg.pyo", line 401, in clone
AttributeError: 'NoneType' object has no attribute 'lookup'
Checking target directory
Target directory does not appear to be the root of a Mogre code tree.
--> Check the repository URL of parameter 'MogreRepository' in your config file.
--> Delete the target directory if still exists. (If a previous cloning was aborted, the content is corrupt.)

Beauty

01-09-2012 14:08:20

SkyX wrapper

I created a task in the MogreBuilder issue tracker:
https://bitbucket.org/mogre/mogrebuilde ... yx-wrapper


There is a second wrapper for the sweet SkyX add-on.
It sounds to be easy to integrate it to the MogreBuilder (as optional add-on)

More information you find here:
viewtopic.php?f=8&t=29491
http://code.google.com/p/mogre-skyx

For the task we have 2 options:
1)
Use the source code from the current repository
--> Find a solution for downloading from SVN
2)
Create a clone in the MogreAddons repository
--> In this case please don't add the media files to the repository directly. I don't want to blow it up by binary files. They aren't needed for building.
Instead we should add them as archive to the download section (as I did for the MParticleUniverse wrapper).


Opinions are welcome.

What do you think is better:
Discuss here in the forum or as posts in the issue tracker?
Advantage of forum: More people can follow and writing is more easy.
Advantage of issue tracker: The whole discussion about the topic is on one place (no mixed discussion as here in the forum)

Tubulii

02-09-2012 18:30:01

Discuss here in the forum or as posts in the issue tracker?
Forum.
I do not look in the issue tracker very often. I do not want to miss something.

It sounds to be easy to integrate it to the MogreBuilder (as optional add-on)
I am sure if that is the best solution. The builder seems to be designed to build one project. You can add new "Tasks" but we would definitly need a real manager.
Such kid of unified manager and builder should have a plugin-system.
Developers should simple provide a plugin .dll or archive that integrates into the manager, downloads all sources, updates references and paths.

I have written a first prototype which seems to work as exspected.
If it becomes stable enough, I could upload it and post a screenshot.

Beauty

02-09-2012 20:53:03

There seems to be different ways how to integrate optional add-ons.

My idea is to have a second, GUI based tool, where you can apply your wanted settings (e.g. add-ons).
The GUI should be created mostly dynamically, based on a list of options (including descriptions), which are created by the MogreBuilder itself.

More details I wrote to a previous post and to the issue tracker #13
Until now it's difficult for users to figure out the MogreBuilder command-line options. I didn't discribed all details of my idea, but I think I have a plan in my mind. This solution would support a good way of "maintaining" options and is useful for automatically generation of help instructions. It also can be used for the GUI tool. When I finished my diploma thesis, I want to continue my MogreBuilder work.


You can add new "Tasks" but we would definitly need a real manager.
Well, maybe our both ideas are a little bit overkill.
How many add-ons or option are planned or needed for the builder?
Maybe 7 Mogre related ones and 7 add-ons?
I suppose to create a manager would take much more time than to create a few additional tasks and options.
We all have not much freetime. So I hope that we don't spend to much on a feature with less priority.

(For example my manager called "FileCopyTask". After I spent much time on it, I wondered if it really was a good decision to do that. Sometimes quick & dirty solutions seem to be more appropriate than "helpers on high level".)

Currently I don't know, which way is better. Yours of mine. Both are possible.

I remember to Zarifus words.
He said to support Ogre 1.8 should be on high priority.
When I continue my work, I want to keep the priorities in mind.
Also in my daily life I should do that.
Well, I just wrote my spontaneous thoughts.

Beauty

02-09-2012 20:55:55

I do not look in the issue tracker very often. I do not want to miss something.
If you click "follow" to the MogreBuilder project, you'll get an e-mail for each comment. (same as for forum posts)
Just to let you know.

Tubulii

03-09-2012 16:35:51

My idea is to have a second, GUI based tool, where you can apply your wanted settings (e.g. add-ons). The GUI should be created mostly dynamically, based on a li.st of options (including descriptions), which are created by the MogreBuilder itselfo.
That was my idea, too. A program which manages addons/plugins. But in my case, MogreBuilder is only used by the Mogre plugin.

Currently my prototyp supports:
- Plugins (loaded at runtime)
- Settings for each plugin
- Grouping of plugins (one click build, individual build mode [debug|Release])
- Different output dirs for each group
- 100% GUI

Future plans:
- Online plugin repository (download from unified source)
- Simple installation/Removal (one click)
- Super simple Plugin system using zip archives and xml
- ...

Until now there are a working plugins for mogre (using a modified version of MogreBuilder) and managed skyx .

Beauty

03-09-2012 20:40:54

Sounds interesting. Does 100% GUI means that plug-ins/add-ons can't be created by a command-line call?
The command-line support would be useful for a build server.

If you are ready to publish it, maybe we can use a second branch of MogreBuilder?
Or are the differences too big? Just an idea.

Tubulii

03-09-2012 22:22:28

The prototype does not depend on mogrebuilder.
Only the mogre plugin uses mogrebuilder (calls it from commandline).
Commandline support could be implemented, currently
there is none.

Does 100% GUI means that plug-ins/add-ons can't be created by a command-line call?
The plugins are not generated. They need to be coded.

Beauty

04-09-2012 10:12:36

Good to know. I misunderstood, because I thought you want to add a plugin-system into the MogreBuilder.

The plugins are not generated. They need to be coded.
I only mean the build process, not the configuration for a new plug-in.

Beauty

04-09-2012 10:49:01

I reinstalled the newer tortoise to get the error I recieved. (And to ensure it still happened after the cmake issue)

Tortoise it self does work though if I tell it to clone the folders created in the process so it's a little odd. Must be somthing to do with the exact command line been passed maybe. Then again older version works so easier to just install that :)


I added a note to the repository front page and readme.txt file:

=========== IMPORTANT === IMPORTANT === IMPORTANT =============
--->
---> There are problems with the new Mercurial version 2.3.
--->
---> So do NOT use TortoiseHG 2.4.3 (contains Mercurial 2.3)
---> Instead USE TortoiseHG 2.4.2 (contains Mercurial 2.2)
--->
---> If somebody find the reason/solution, please tell us.
--->
===============================================================

Tubulii

04-09-2012 19:38:31

My prototype is nearly finished:
- Plugins (loaded at runtime)
- Settings for each plugin
- Grouping of plugins (one click build, individual build mode [debug|Release])
- Different output dirs for each group
- 100% GUI
- Online plugin repository (download from unified source) [using dropbox and zip archives]
- Simple installation/Removal (one click)

Future plans:
- Super simple Plugin system using zip archives and xml

Requierments:
>Vista, WinXp is untested.
.Net 4
A LOT OF free space on C:\ (can be changed)

As soon as I managed to test it in a clean Windows, I will upload it for public testing.

Good to know. I misunderstood, because I thought you want to add a plugin-system into the MogreBuilder.
No problem, my first attempt actually was to extend MogreBuilder, but it has been designed to be a commandline program. My GUI solution seemed "wrong" ;)

zarfius

05-09-2012 04:37:21

Sounds interesting. Does 100% GUI means that plug-ins/add-ons can't be created by a command-line call?
The command-line support would be useful for a build server.

No problem, my first attempt actually was to extend MogreBuilder, but it has been designed to be a commandline program. My GUI solution seemed "wrong"
Yes, MogreBuilder was designed as a command line tool specifically so it can be used in a build server. However, there's no reason why it can't have a GUI sitting on top of it. Essentially, the GUI just needs to be able to change settings in MogreBuilder's configuration file and everything should work okay. What you've done Tubulii sounds like a great idea. I'm sure it will go nicely with MogreBuilder.

Tubulii

05-09-2012 18:28:30

OK, Here is my prototype: Download.
It should work, but could not test it on another machine because VS 2010 was not installed. It works (=starts ;) ) under WinXP.
This is not the final version and use at own risk!

If you encounter errors, delete "Plugins" folder in main directory and all *.config files, too. If you wish, you can also delete C:\MCB\*. This will reset the whole program.
An internet connection is requiered.

Update (v0.9): Fixed various bugs and tested it on another machine: It works!
Replaced files on dropbox with new ones.

Update (v0.9.5): Added two new plugins:
- Utils (manages svn, cmake, git and hg)
- MyGUI (modified to work with .Net 4 + some other modifications, see header files in plugin dir for hints)
Replaced files on dropbox with new ones.

WinXP support is untested, but it should work (Taskdialog is emulated).
Mono is not supported because P/Invoke is used.
Admin rights are required (some times cmake needs them).

And a bit promotion ;) :

Beauty

07-09-2012 00:47:15

Essentially, the GUI just needs to be able to change settings in MogreBuilder's configuration file and everything should work okay.
Several settings are done by the config file, but currently you can't do all with it.
Some settings can only be applied by command-line parameters.
I thought about integration to the config files, but had arguments against it. (I think I posted them somewhere in this huge topic.)
Instead I wrote a few different *.bat files to apply my wanted settings (config file, target path, add-ons, etc.).

there's no reason why it can't have a GUI sitting on top of it.
My plan is to use a seperate application (exe file) for this task. (as you read some posts above (here))
I think this is more clear than a mixed command-line / GUI application. (Just my personal opinion.)

OK, Here is my prototype: Download.
Nice to see, but unfortunately I can't test it yet. My diploma thesis ...

crankyslap

15-10-2012 11:40:29

Trying to get MogreNewt to work with Mogre 1.7.4. I tried to use MogreBuilder with -mogrenewt -onlyaddons but it keeps on moaning about the "directory of the Newton library not being defined. Either add the path to paramter *** or put the files in C:\Mogre\MogreAddons\MogreNewt\MogreNewt_Main\input_Newton\"

So I did put the Newton files in there but the error remains the same... is there a folder structure I need to uphold? And what version of Newton can I use? I am trying to use 2.20 because that's what came with the MogreSDK.. but the MogreSDK has Mogre version 1.7.1 and I need 1.7.4 .. but I still want to use Mogrenewt.. what do I do now, please?

Beauty

29-10-2012 15:53:12

MogreNewt

I published an updated version of MogreNewt, which can compile against Newton 2.35.
Additionally I wrote some build instructions.

More details you find here:
viewtopic.php?p=100289#p100289

Beauty

29-10-2012 16:00:27

option "-onlyaddons"

I tried to use MogreBuilder with -mogrenewt -onlyaddons

For the first run you have to compile Ogre/Mogre, because several created files are needed to build MogreNewt.
Only when Ogre/Mogre was already compiled, you are allowed to use the "-onlyaddons" option.

What happens when the "-onlyaddons" option is used?
It skips the build process of Ogre/Mogre.
I know - it's difficult to know, because I wrote no documentation.

Beauty

29-10-2012 16:46:27

Problems with Mercurial

Just a heads up the latest tortoise (tortoisehg-2.4.3-hg-2.3-x64) gave errors using the builder it was in the hg.exe for some reason?? but using the previous build all works ok (tortoisehg-2.0.5-hg-1.8.4-x64)

Your recognized problems happened with TortoiseHG 2.4.3 (contains Mercurial 2.3.0).

Now there newer versions are available (currently TortoiseHg 2.5.1, contains Mercurial 2.3.2)
http://tortoisehg.bitbucket.org/download

It would be nice if somebody can perform a test if the problems are solved with the latest TortoiseHG version.

Beauty

11-12-2012 21:14:05

Changelog

Thanks to Caprico!

He improved the MogreBuilder:
Now you just need to clone (download) the repositories once.

If you run MogreBuilder again (with the same target directory), it updates the local repositories (if updates are available).
To avoid problems with previously generated files, the working directories are cleaned up automatically before starting the build/wrapping process again.

For details have a look to the commit and the bugtracker issue #17.


Are there any news related to the Mercurial problem?
(Maybe the problem is solved by using the latest TortoiseHG version?)

Beauty

17-12-2012 22:10:18

Our new community member Ascendion tries to update Mogre to 1.8.
Caprico got some experience, too (some months ago).

Have a look to this topic for further information:
MOgre 1.8 1st attempt

Caprico

27-12-2012 10:14:03

Changelog

I have made some other changes to MogreBuilder:

  1. MogreBuilder supports Visual Studio 2012 (since a few weeks already but no one has written about it yet).
    Call MogreBuilder with the command line option "-vs2012".
    [/*:m]
  2. MogreBuilder can now compile for x64.
    Call Mogrebuilder with the command line option "-x64" to do that.
    [/*:m]
  3. You don't need to specify the path to CMake in your config file anymore.
    Leave out the option "CMakeExecutable" in your config file or set it to "cmake.exe" (without any path) and MogreBuilder will use the CMake available on your system path.[/*:m][/list:u]

    ----------
    Are there any news related to the Mercurial problem?
    (Maybe the problem is solved by using the latest TortoiseHG version?)

    I was using TortoiseHG 2.5.1 for a few weeks and now I am on 2.6.1. I did not have any problems with any of these versions.

Beauty

27-12-2012 18:49:21

Thanks for your improvements and the changelog in this forum topic.
Also it's nice to read that the HG problems are solved. So we can remove the warning.

Beauty

30-01-2013 19:47:00

Here is an other forum topic about a MogreBuilder problem: MogreBuilder has error!

kelebra

14-10-2014 13:48:18

I have an issue

Running CMake again to include fresh built Ogre depencies
Could not register CMake's Visual Studio macros file 'CMakeVSMacros2.vsmacros' while Visual Studio is running. Please ex
it all running instances of Visual Studio before continuing.
CMake needs to register Visual Studio macros when its macros file is updated or when it detects that its current macros
file is no longer registered with Visual Studio.
CMake Error at C:/Program Files/CMake/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler "f:/Program Files/Microsoft Visual Studio
10.0/VC/bin/cl.exe" is not able to compile a simple test program.
It fails with the following output:
Change Dir: D:/myMogreBuild/Main/OgreSrc/build/CMakeFiles/CMakeTmp
Run Build
Command:"C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe"
"cmTryCompileExec688373441.vcxproj" "/p:Configuration=Debug"
"/p:VisualStudioVersion=10.0"
Microsoft (R) Build Engine версии 4.0.30319.19408
[Microsoft .NET Framework версии 4.0.30319.19448]
(C) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.
Сборка начата 14.10.2014 18:37:35.
Проект
"D:\myMogreBuild\Main\OgreSrc\build\CMakeFiles\CMakeTmp\cmTryCompileExec688373441.vcxproj"
в узле 1 (целевые объекты по умолчанию).
PrepareForBuild:
Создание каталога "cmTryCompileExec688373441.dir\Debug\".
Создание каталога "D:\myMogreBuild\Main\OgreSrc\build\CMakeFiles\CMakeTmp\Debug\".
InitializeBuildStatus:
Создание "cmTryCompileExec688373441.dir\Debug\cmTryCompileExec688373441.unsuccessfulbuild", так как было задано "Alw
aysCreate".
ClCompile:
f:\Program Files\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _D
EBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec6
88373441.dir\Debug\\" /Fd"cmTryCompileExec688373441.dir\Debug\vc100.pdb" /Gd /TC /analyze- /errorReport:queue testCCompi
ler.c
Оптимизирующий 32-разрядный компилятор Microsoft (R) C/C++ версии 16.00.30319.01 для 80x86
(C) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.
cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd
/GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec688373441.dir\Debug\\" /Fd"cmTryCompileExec688373441.dir\D
ebug\vc100.pdb" /Gd /TC /analyze- /errorReport:queue testCCompiler.c
testCCompiler.c
ManifestResourceCompile:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /nologo /fo"cmTryCompileExec688373441.dir\Debug\cmTryCompil
eExec688373441.exe.embed.manifest.res" cmTryCompileExec688373441.dir\Debug\cmTryCompileExec688373441_manifest.rc
Link:
f:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:"D:\myMogreBuild\Main\OgreSrc\
build\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec688373441.exe" /INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib wi
nspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /ManifestFile:"cmTryCompileEx
ec688373441.dir\Debug\cmTryCompileExec688373441.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='fal
se'" /DEBUG /PDB:"D:/myMogreBuild/Main/OgreSrc/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec688373441.pdb" /SUBSYSTEM
:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"D:/myMogreBuild/Main/OgreSrc/build/CMakeFiles/CMakeTmp/Debug/cmTryComp
ileExec688373441.lib" /MACHINE:X86 cmTryCompileExec688373441.dir\Debug\cmTryCompileExec688373441.exe.embed.manifest.res
cmTryCompileExec688373441.dir\Debug\testCCompiler.obj /machine:X86 /debug

Beauty

16-10-2014 19:38:13

Hi Kelebra,

nice to see you here in our Mogre forum.

Running CMake again to include fresh built Ogre depencies
I'm not shure what you mean exactly.
Do you mean you mean you used MogreBuilder once and later you tried process the CMake files in the target directory?
I didn't work with Mogre for two years now.
As far as I remember, you just need to run MogreBuilder (once) and during the build process the Ogre depencies are downloaded, built and included to the Ogre/Mogre binaries automatically.
If you only need the depency files, you should find them somewhere in the target directory. Either in the binary output directory (yourTargetDirectory \ bin \ Release.NET4) or somewhere else.

To be shure, use an empty target directory. (Delete the previous built content or use an other target directory.)
Reason: When you call MogreBuilder twice, there can be some effects with the CMake files.
I don't remember details, but maybe the reason was, that the CMake files will not re-created (with default settings) when they are already inside of the output directory. But I'm not shure.

Your logs looks like that you use Visual Studio 2010. Is it right?

alamata

19-10-2014 07:29:10

Hey to all,...

i try to use MogreBuilder but i cant clone the repository :

abort error getaddrinfo failed
could not clone repository https://bitbucket.org/moge/mogre/ to C:/myMogreBuild


i have tried with several version a tortoise hg with no result.... :?

what 's wrong ,... :?: :?:

thx for your comprehension,...

BrainScan

19-10-2014 07:45:35


abort error getaddrinfo failed
could not clone repository https://bitbucket.org/moge/mogre/ to C:/myMogreBuild


If that is the exact error message, it looks like you have a typo in your config (missing an "r"). The address should be: https://bitbucket.org/mogre/mogre

alamata

19-10-2014 07:51:32

Hey,...


it s not the exact message i have recopied,
the ""r"" is present in the exact message from the console

alamata

19-10-2014 11:51:03

Can somebody tell me with wich version of tortoise HG he use to run optimally MogreBuilder
can this person make a test to see is there a issue too at this time ,...

thx in advance,...

Beauty

20-10-2014 00:56:58

Since a half year I have a new PC.
So now I installed the needed software (CMake and DirectX SDK).
Then I updated and re-build MogreBuilder.
Later I started MogreBuilder with the default configuration file (without changes) by call of file RUN_example.bat.
Result: Mogre was built successfully.

Used software:
* Visual Studio (I have 2010 and 2012 and suppose version 2010 was used, because I don't added the -vs2012 option)
* CMake version 3.0.2 (latest)
* TortoiseHG 3.1, which includes Mercurial version 3.1+2 (strange number)
* DirectX SDK (June 2010)


abort error getaddrinfo failed
could not clone repository https://bitbucket.org/moge/mogre/ to C:/myMogreBuild

I don't know this error.
Maybe there are wrong proxy settings for Mercurial?
Try to clone the Mogre resitory manually to see if it's a problem of Mercurial or MogreBuilder.

alamata

20-10-2014 09:27:54

Hey,...

Try to clone the Mogre resitory manually to see if it's a problem of Mercurial or MogreBuilder.

i have followed these instructions for the manual build,...and .. everything is ok manually,...

https://bitbucket.org/mogre/mogre/src/4 ... at=default

For the error ""abort error getaddrinfo failed""

""
The getaddrinfo() and getnameinfo() functions are part of the POSIX standard application programming interface (API) for converting domain name system (DNS) hostnames and IP addresses between their human-readable text representations and structured binary formats for the operating system's networking API.""


see http://en.wikipedia.org/wiki/Getaddrinfo

Beauty

20-10-2014 21:43:11

Here is the code section (in file RepositoryTask.c), which throws the exception:


// create directory if needed
if (!Directory.Exists(target))
{
Directory.CreateDirectory(target);
outputManager.Info("Created directory: " + target);
}

if (RunCommand("hg", string.Format("clone --verbose {0} -u {1} {2}", repositoryPath, branch, targetPath), null).ExitCode != 0)
{
throw new Exception(string.Format("Could not clone repository {0} to {1}", repository, target));
}


Can you try to call the clone command as the RepositoryTask on command-line?
MogreBuilder does the same call (but without visible command-line).
hg clone --verbose https://bitbucket.org/sinbad/ogre/ -u v1-7 c:\test_OgreCheckout

alamata

21-10-2014 22:51:30

Hey,...


Can you try to call the clone command as the RepositoryTask on command-line?
MogreBuilder does the same call (but without visible command-line).
hg clone --verbose https://bitbucket.org/sinbad/ogre/ -u v1-7 c:\test_OgreCheckout



Everyhting seems ok with that command line,...

alamata

22-10-2014 14:44:09

Hey,...

So if the command have passed
that sould be surely a issue relative to protection level of file

so i have do that:

in Run_Example.bat

C:\myMogreBuilder\MogreBuilder.exe C:\Mogre3D -config "C:\myMogreBuilder\Default.cfg"
pause


and then create a shortcut to it."" Run_Example.bat - shortcut"". then right click on ""Run_Example.bat - shortcut"" ->Properties->Shortcut tab -> Advanced and click Run as administrator.

Execute it from the shortcut.

and everything perfect,...

Voila,... ;)

Beauty

25-10-2014 17:17:24

I don't need to agree to admin rights when I call the batch file.
Do you need admin rights, when you use HG to checkout code by command-line?

Calling the batch file with admin rights solved the HG problem?
Strange!

Which Windows version do you use?
Do you have a user account with admin rights oder with restricted rights?

alamata

25-10-2014 20:04:37

Hey,...

here is the situation,...




Do you need admin rights, when you use HG to checkout code by command-line?


Nope


Calling the batch file with admin rights solved the HG problem?
Strange!


yes it is,...

Which Windows version do you use?


Win 8.1 64


Do you have a user account with admin rights oder with restricted rights?


yes i have,...

Beauty

25-10-2014 21:55:09



Do you have a user account with admin rights oder with restricted rights?


yes i have,...


Yes what?

alamata

25-10-2014 23:19:57



Do you have a user account with admin rights oder with restricted rights?


yes i have,...


Yes what?


i have an user account with admin rights

alamata --Administrator protected with password

Beauty

21-11-2014 18:04:35

New feature: HTML logfile

Today I implemented an idea, which I had in mind for a long time.
Now MogreBuilder creates a log file in HTML format, because the coloured text gives a better overview.

Currently the file will be created in the same directory as MogreBuilder.exe.
Just double click the file MogreBuilder_logfile.htm and your browser shows the content.

ali_lak

15-10-2016 11:49:53

Hi,
I have some experience with Ogre. but now i wanna to use Mogre.
for install mogre, after some search i found this page:
http://www.ogre3d.org/tikiwiki/MogreBuilder
at this page there is a link to download MogreBuilder. but it doesn't work correctly, this line:
https://bitbucket.org/mogre/mogrebuilder

is there another way to download it?

Note1: I'm so sorry for my bad English.

Thank you very much.

Beauty

03-11-2016 20:27:28

Hi Ali,

welcome to the Mogre world.
I'm very sorry for my late answer.
I saw your message, had no time in that moment and then I forgot it.

On the usage description I wrote "download MogreBuilder".
Well, better would be to write:
Install TortoiseHG (a client for the source control system Mercurial) and clone the repository.
The link I referenced in the usage description.

After cloning the repository to your computer you can open and compile the MogreBuilder project with Visual Studio.
In normal case you just call compile and should get the exe file without problem.
Well, I don't work in the 3D area for some years now. So I didn't test it with the current VS version.

If you have problems, just tell me (here in the forum topic).

Beauty

03-11-2016 20:38:35

If you mean you just want to download the precompiled Mogre DLLs, take package 1 from this link:
viewtopic.php?p=100349

It's 4 years old, but is good for first tries.

Read my notes in the first post of the link.
Install the dependencies for that binaries.