Build system discussion

Newcomer Posts : 94 Reputation : 15 Join date : 2013-03-18

As Danni mentionned, the problem I had was on my part. I am using Comodo Internet Security Premium. It has a Behavior Blocker that ask me what permission I want to give to any program that are run for the first time.

While installing, it popped up about some kind of .jar file I think(can't remember the exact name). I gave it permission and restarted the installation to make sure it didn't cause problem. When I installed yesterday, it asked me again to give it permission. I found it strange and decided to just close Comodo and run the installation again. Everything went fine and all the Failed Copy disappeared and all went quite smoothly. It still took me around 2h even if I had all the file in the temp folder. Apologies for making you search for a solution to a problem on my part.

I'll give you the requested information although Danni already gave you his. At first glance it seems to be identical but I figured having another build log on a different machine wouldn't hurt.

Vanilla Cmake log asking for OIS :

Spoiler:

Vanilla CMakeCache asking for OIS :
https://dl.dropboxusercontent.com/u/156274557/CmakeCache_Hardcoded_SDK_OGRE.txt

First time i just pointed OIS dir to its own directory. After reading last posts, I decided to point OGRE_SDK empty string toward it's folder "C:\MinGW\OgreSDK"
Configuration worked.

Cmake log after hardcoding OGRE_SDK string. As you'll see, it is missing PKG_CCONFIG_EXECUTABLE (Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE))

Spoiler:

CMakeCache after hardcoding SDK_OGRE
https://dl.dropboxusercontent.com/u/156274557/CmakeCache_Hardcoded_SDK_OGRE.txt

I then opened cmd prompt as administrator, changed directory to "E:\GitHub\Thrive\build" and used mingw32-make instal. Everything went smoothly.

When I try to run "E:\GitHub\Thrive\build\Thrive.exe", i get the following error :
The program can't start because libboost_system-mt.dll is missing from your computer. Try reinstalling the program to fix this problem.

However, I'm pretty happy to say that running "E:\GitHub\Thrive\build\dist\bin\Thrive.exe" works! I'm able to move the ogre model. Is it an artifact from the old build method or is it the Thrive.exe i'm supposed to run? I deleted the whole build folder before running cmake.

It's not really important right now, but I think it's worth poiting it out. When I only have my laptop(16:9 ratio), Thrive goes full screen perfectly. When I have my second monitor(4:3) connected, thrive will run on half of the second screen whatever the screen I execute it from.

I probably gave too much information, but I want this build system to work fine so we can actually work on making a game I also learned that trying to post 1800 line of text raise an error 500! First thousands previewed well though.

Subject: Re: Build system discussion Fri Apr 12, 2013 11:04 am

RodGame wrote:: Apologies for making you search for a solution to a problem on my part.

Absolutely no apologies necessary. No one could have known that a virus scanner would cause such error messages. It's actually a lucky coincidence that it happened to you. I'll include a "Troubleshooting" section in the Readme that will advise the user to disable virus scanners and similar during installation if they run into problems.

Quote :: It still took me around 2h

That's quite long, mine never takes more than maybe half an hour. What kind of hard drive are you using?

RodGame wrote:: Cmake log after hardcoding OGRE_SDK string. As you'll see, it is missing PKG_CCONFIG_EXECUTABLE (Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE))

That's normal, I get that too.

RodGame wrote:: When I try to run "E:\GitHub\Thrive\build\Thrive.exe", i get the following error [...]

That's to be expected. As you already noticed, the "dist/bin/Thrive.exe" is the "right" one. It's actually a copy of the same file, but the install procedure copies all the necessary libraries to dist/bin so the application can find them.

Newcomer Posts : 94 Reputation : 15 Join date : 2013-03-18

I'll just answer to all question of the post above mine without quoting for simplicity's sake.

- Just to be clear, it wasn't my anti-virus, it's a Behavior Blocker, something that Block/Sandbox software that are not safe. I choose what to do with each software myself but the average user will probably ask for Comodo to deal with it itself. I think it's a really good idea to advise user to disable any kind of anti-virus/firewall if problems come along the way. As you said, it would have been hard to make a link between a Failed Copy and an anti-virus/Behavior Blocker. I compiled a small list of thing I'd see added to the readme. I'll eventually give them to you when we are "done" with the build system.

- My Hard drive is a Western Digital 5400 RPM(best link I found from the name in my device manager). Well it turns out I have 2x500gb. I always tought I had 1x1000gb.

I might have found the issue. My setup.ps1 and github files are in the E:\ partition. I install MinGW on the C:\ partition. My E:\ is 465gb so they probably are on two different disk. However all the information are downloaded straight to the C:\MinGW\temp folder and installed from there. Apart from being executed from the E:\ partition, all the transfert are done on the C:\ partition so I don't see a lot of work being done between the 2 drivesd. Could it still be the issue? I'll try to run everything from the C:\ partition and measure how long it take.

- OK

- Nice way to have a working executable even if some links are broken. This mean we're getting there!

Subject: Re: Build system discussion Fri Apr 12, 2013 2:13 pm

I just pushed a fix for the OIS issue. I also added the Google test framework to the installation procedure so we can implement unit tests.

Subject: Re: Build system discussion Mon Apr 15, 2013 3:55 am

I just tried the setup script again and it is not working. It seems to give out the exact same error (cannot find OIS)

Just to be sure, you pushed it to the Daniferrito branch?

Here it is the CMakeCache file.
https://www.dropbox.com/s/liua8qbuavr9j0z/CMakeCache3.txt

I ran the script into C:/MinGW_Nimbal, not C:/MinGW.

Subject: Re: Build system discussion Mon Apr 15, 2013 4:22 am

Huh. The toolchain-win.cmake file in the repository doesn't contain the fix I intended to push. I must have had my files mixed up. Anyway, I'll push it later when I'm back home.

Subject: Re: Build system discussion Mon Apr 15, 2013 12:54 pm

I just ran the updated script and it works now. Cmake runs without problem and the code succesfully compiles. The code:blocks project works as well.

As far as i'm concerned, it is ok for merging. Do you want me to accept the pull request or do you want to do further changes? I also agree with you that probably merging everything into the main branch would be good. I'll probably do that unless someone has something against it. Anyway, the code at the main branch is quite outdated.

Finally, what could i work on? You've got so much code done and so many changes that i dont know what to do without steping on your toes. I will probably do some of the preparation for implementing AI if there is nothing more inmediate i find.

Subject: Re: Build system discussion Mon Apr 15, 2013 1:09 pm

Sure, go ahead and merge it. If someone finds another issue, we can just as well fix it in the main repository.

Daniferrito wrote:: Finally, what could i work on?

Not much actual code yet, I'm afraid. I'm still pondering how to best handle the synchronization between multiple threads, and depending on how we go ahead with this, some pretty fundamental things will change yet again.

I'll make a post about that in the Engine Architecture discussion momentarily, together with suggestions for what you (and other programmers) could do until the basic engine is up and running.

Subject: Re: Build system discussion Thu Apr 18, 2013 8:07 am

I found another problem with the setup script. This time, i started from a completelly clean and fresh computer, recently formated.

I ran the script pointing it to C:/MinGW-Thrive. I have to note that i dont have a C:/MinGW folder, and this was my first MinGW on the computer. Of course, i had installed CMake and Code:Blocks.

The script was ok (or at least it seemed to be ok). However, when i try to run CMake, it gives errors.

Here it is the error log:

Spoiler:

The problem is that it is unable to find the make program, which i believe is mingw32-make.exe. It seems to search for it on the path and on C:/MinGW/bin, but not on C:/MinGW-Thrive, where it is.
If I run the script on C:/MinGW, it runs without errors, and I am able to compile it.

This error only happens if you run the script on a diferent folder than in C:/MinGW while you dont have a MinGW instalation alredy there, which is discouraged by the readme.

Subject: Re: Build system discussion Thu Apr 18, 2013 8:13 am

I could have sworn I added that to the readme. I'll update that at the next opportunity. You basically have to manually set the CMAKE_MAKE_PROGRAM variable to the mingw32-make.exe. There's no way around it because CMake (or at least the CodeBlocks generator) checks for this before even looking at the toolchain file, so setting that variable in the toolchain file has no effect.

Subject: Re: Build system discussion Thu Apr 18, 2013 8:20 am

My fault, it is alredy there, i didnt saw it.

Subject: Re: Build system discussion Wed May 08, 2013 3:59 pm

Due to a bug in either gcc 4.8 or the luabind library, I need to downgrade the build system to gcc 4.7. The precompiled Ogre SDK available to download is incompatible with the usable mingw builds I found, so we'll need to build Ogre from source. I actually like this prospect because it allows us more control.

It also opens the option to compile for 64 bit Windows (the precompiled Ogre SDK was 32 bits only). In principle, it's possible to support both 32 and 64 bit versions, but they'd need to be separate build chains. I can add an option for that later, if necessary.

The question is, does anyone here still use a 32 bit system? Do we even want to support such systems?

Subject: Re: Build system discussion Wed May 08, 2013 4:34 pm

I'm ok going 64 bits. Any computer built in the last five years i've seen uses it alredy, and taking into acount the scope of the game, older computer wont be able to run it too well.

I've looked at some statistics, and about 3/4 of all computer users use windows 64 bits. However, win32 users greatly outnumber all the linux users together, and we are still suporting linux.

My vote goes for compiling it for 32 or 64 bits for now (one of the other, althrough 32 is more compatible), but eventually change the script to work for both if we feel we need to. Unless i'm missing something coding shouldn't change, so we dont have to worry too much about it.

Subject: Re: Build system discussion Sat May 11, 2013 10:54 am

I just pushed the latest version to the Lua branch. As I already mentioned in another thread, generating 64 bit executables proved to be too much trouble. The main changes to the build system:

Downgrade from gcc 4.8 to gcc 4.7 due to incompatibilities with luabind, as described here
Upgraded from Boost 1.51 to Boost 1.53
Ogre is now compiled from source

I recommend deleting your old build system directory.

Subject: Re: Build system discussion Sat May 11, 2013 11:01 am

I downloaded it a few hours ago, and when i checked gcc to see the version, it still said 4.8. I made sure do delete all previous mingw folders and ran the script on C:/MinGW.

I see you just pushed an update 5 mins ago, but you only changed the readme.txt, so i dont think the script should change its behaviour. Anyway, i'm runing it again to see if it still installs gcc 4.8.

BTW, i tried compiling and it complained about luabind. I supose that is the problem you are having with gcc 4.8?

Subject: Re: Build system discussion Sat May 11, 2013 11:10 am

The change to the readme was an afterthought. The actual changes are in the commit(s) before that.

And yes, luabind was the culprit (although it might very well be a compiler bug with gcc 4.8, I'll have to investigate further). But it could be that the error you saw stems from another small issue I forgot to mention. I've added git submodules (i.e. references to other git repositories) to the googletest framework and luabind. Those submodules will have to be initialized before they contain anything. If you are using TortoiseGit, you can do that with "Submodule Update" in the right-click context menu. Make sure that "init" is checked in the dialog that pops up and click ok.

If you are using a command line git client, the command for initializing the submodules is "git submodule update --init".

Subject: Re: Build system discussion Sat May 11, 2013 11:22 am

Hmmm, i was only downloading the whole folder as .zip. Not any git client or anything. I'm going to look into that while the current script runs.

The script is currently working on boost, so mingw is alredy installed. I checked, and now it says the version is 4.7.3. I dont know why it was saying 4.8 before.

Actually, the error it was telling me was missing .hpp files. I checked, and they were indeed not there.

Subject: Re: Build system discussion Sat May 11, 2013 11:26 am

I just tried, and the zip generated by GitHub doesn't contain the submodules. That would definitely explain missing header files. You'll have to clone the repository, I'm afraid.

Subject: Re: Build system discussion Sat May 11, 2013 12:01 pm

Ok, i downloaded git, tortoisegit, and cloned the repo with the submodules. However, the script is failing to compile OGRE. Here is the log:

Spoiler:

Subject: Re: Build system discussion Sat May 11, 2013 12:06 pm

Looks like the dependencies weren't installed correctly. Did you have any error messages in the step before that?

Subject: Re: Build system discussion Sat May 11, 2013 12:33 pm

I ran it again and it seemed to have an error at ogre dependencies and cmake. However, it passes way too fast for me to be able to copy it. Is there a way of dumping the log into a .txt file? I dont know how to work with powershell.

If i look at the temp folder, it downloaded the .zip that contains the dependencies, but it didnt unpack them. I downloaded the .zip file manually and it ocupies exactly the same amount of bytes.

I got the log by adding

$shell = new-object -comobject wscript.shell
$shell.popup("Wait",0,"",0)

at the end of the ogre dependencies script. However, it didnt fail this time. I believe it is because i unziped the downloaded package manually by rightclick>extract here. Ogre is building now.

I'll rerun the script after deleting the folders later, to see if it still gives me the error, or it just didnt want to behave temporarly.

Subject: Re: Build system discussion Sat May 11, 2013 12:46 pm

Ah, thanks for the detective work. Impatient as I was, I commented out the line where the dependencies archive was unpacked to save some time during testing and promptly forgot to comment it back in. It's fixed now.

Subject: Re: Build system discussion Sat May 11, 2013 1:05 pm

Ok, got it working. It definetly does... something.

The input part doesent work too well. It seems like it doesent get that a key has been released sometimes. Either we change how it works on the lua side, or we made the other side more reliable. Can you point me where the other side is? Where the events come from. I'll see if i can make it more reliable.

Subject: Re: Build system discussion Sun May 12, 2013 8:51 pm

Ok guys, I wish to start helping, do I just follow the main post like I did before or was there a change?

This is getting bad, only 2 active programmers, I cannot allow this. So I have to help.

Nimbals comment about the 'bus factor' pushed me off the edge.

Subject: Re: Build system discussion Sun May 12, 2013 11:33 pm

There has been some changes on the set-up script, so you will have to delete previous instalationsof the script and run it again. If you have a clean MinGW instalation in C:/MinGW, i recomend you to move it or rename it so you can run the script in C:/MinGW (just in case).

Nimbal added submodules to the git repo, so you will have to download them as well. For that, follow the instructions on this Nimbal's post:

Spoiler:

For now, the repo with the most updated sources is nimbal's thrive (lua branch), but i intend to merge that into the main repo.

Just follow the steps in the readme, that hasn't changed.

On Code::Blocks, i found out a way of runing the game from the environement while on IRC with Nimbal. To do so, right click the project>propierties>build targets>install. There, change the type from commands only to gui aplication, specify the output filename as Thrive.exe and set the execution working dir as dist\bin. That even allows you to debug from Code::Blocks (althrough i recomend you not to run it on fullscreen to do so).

The documentation with doxygen is awesome, once you get it working. There is probably a better way, but i had to download doxygen, put the executable on the doc folder, edit the doxygen.cfg.in so INPUT points to ../src and run doxygen doxygen.cfg.in in the command line. Again, either there is a better way i missed or .gitignore prevented the right files from being uploaded to the repo.

Edit: I just merged the pull request. There were conflicts for some files in the set-up script. I used the changes from nimbal's repo.

» Revamping the Forum
» Development troubleshooting
» Build Error Code::Blocks / CMake
» Outreach Discussion
» Programmer coordination discussion