ubuntu C::B questions

[Michael]

Hello,

Yesterday, I have build my first C::B in ubuntu 5.10 . It was a bit difficult at the beginning (I am also a ubuntu newbie), but with the precious help of Daniel2000, the C::B wiki turorial and a Pecan's topic, I got it done . The version in question is rev2133 (gcc 4.0.2 Linux/unicode).

I have remarked a small problem. In the compiler's settings -->Programs-->Program Files, the Resource compiler label and combo are cut by half. Has someone else remarked this or it is just a local problem?

I have also remarked that the code completion cache has been de-activated and will be later taken out. Could I ask why?

I also would like to ask about building C::B in ubuntu. In Windows, after updating the project, I opened it and compiled C::B. In ubuntu, after updating the project with SVN, should I do

make unistall
./configure
make
make install

Or it would be simplier with the CodeBlocks-unix.cbp? I ask because make take me more than 1 hours to be completed :roll:.

I have also had problems by using make install, because of permission problems. I had to do sudo -i and then make install. I suppose that doing make unistall will require root rights? To avoid these "problems" should I build C::B by using a root shell?

Thank you very much.

Best wishes,
Michael

[Alux]

Code: bash

sudo make unistall
./configure
make
sudo make install

should do it - and im not even totaly sure you need to uninstall beforehand (feel free to correct me!)

one hour is quite a long build time in this case i think... what are your system specs?
also - once youve built once updating from svn should only get files that have changed, and make should only recompile files that have changed...

btw, depending on how new to ubuntu/linux you are
www.ubuntuguide.org (though for 5.04) has lots of handy info, and the offial wiki is crammed with helpfull info too
whats more there are a couple of handy apps such as easyubuntu(quite safe i tihnk) and automatix(heard complaints,mainly from people who tried to dist-upgrade after using this) that can install all sorts of goodness automaticly (such as a whole bunch of codecs, new ver of wine, java 1.5 etc)

[mandrav]

Code

sudo make unistall
make
sudo make install

This should do it. Note that you must uninstall first, or else when linking the app and plugins it uses the libcodeblocks.so previously installed (instead of the one you create with 'make'). Don't know why yet...

And, of course, don't forget that you can build it using codeblocks-unix.cbp
After you build C::B succesfully once using 'configure' and install it, you can build C::B using itself. So everything will be like in windows world (run 'update' afterwards, etc).

[Michael]

Code: bash

sudo make unistall
./configure
make
sudo make install

should do it - and im not even totaly sure you need to uninstall beforehand (feel free to correct me!)

Thank you . I am not sure that I have to unistall it. May be just when I will have some compilitation/linking issues. I was wrong here. Sorry. Mandrav pointed out that you have to first make unistall.

one hour is quite a long build time in this case i think... what are your system specs?

I have a Desktop with PIII 500 MHz and 512MB RAM. It is not the maximum, but it is only thing I have got from my institute (as secondary computer). And ubuntu works relatively fine (much better than a Windows XP would have been done .

also - once youve built once updating from svn should only get files that have changed, and make should only recompile files that have changed...

In this case, I should avoid a make unistall. If not it will re-build all from the beginning.

btw, depending on how new to ubuntu/linux you are
www.ubuntuguide.org (though for 5.04) has lots of handy info, and the offial wiki is crammed with helpfull info too
whats more there are a couple of handy apps such as easyubuntu(quite safe i tihnk) and automatix(heard complaints,mainly from people who tried to dist-upgrade after using this) that can install all sorts of goodness automaticly (such as a whole bunch of codecs, new ver of wine, java 1.5 etc)

Thank your for the info.

Actually, I am fighting with the root's permission. I have my C::B executable in /usr/local/bin, but I cannot do a shortcut to put in my desktop .

Best wishes,
Michael

[Michael]

Code

sudo make unistall
make
sudo make install

This should do it. Note that you must uninstall first, or else when linking the app and plugins it uses the libcodeblocks.so previously installed (instead of the one you create with 'make'). Don't know why yet...

Ah, Ok. So, I was wrong in my previous post (I will edit it). Thank you for pointing this out .

And, of course, don't forget that you can build it using codeblocks-unix.cbp
After you build C::B succesfully once using 'configure' and install it, you can build C::B using itself. So everything will be like in windows world (run 'update' afterwards, etc).

I think I will be more comfortable with this solution . I have quite never used make and friends, but I suppose that it should not be so difficult to understand and use them.

Best wishes,
Michael

[Game_Ender]

With any hope you shouldn't have to do a full rebuild every time, make is smart enough to work out the dependencies and only rebuild what is needed based on file changes.  I would also stick with make when building codeblocks (if your are working on CB itself its obviously better to use CB to build itself), especially if you aren't doing a full rebuild.  Make is currently the fastest build system and I doubt that codeblocks custom system is any faster.  I will test this though.  Currently when I do a full rebuild I do the following:

Code

# Gets rid of all created files
make distclean
svn up
# These two are just to make sure I catch any changes to these files
./bootstrap
./configure --prefix=/home/myusername/Apps/codeblocks-svn
make
make install

I have never had to "make uninstall", make just overwrites the old files in my home directory.

[Michael]

Code

# Gets rid of all created files
make distclean
svn up
# These two are just to make sure I catch any changes to these files
./bootstrap
./configure --prefix=/home/myusername/Apps/codeblocks-svn
make
make install

Thank you for your help and explanations . I will give it a try.

Best wishes,
Michael

[takeshimiya]

I will test this though.

If you're going to test it, just make sure to disable all plugins except the Compiler plugin (CodeCompletion esp. is known to make the build slower).

Or test both cases.

[mandrav]

Make is currently the fastest build system and I doubt that codeblocks custom system is any faster.

I would doubt that, but feel free to test it and share your findings with us

[Game_Ender]

I would doubt that, but feel free to test it and share your findings with us

Will do, but please see reviews of other build systems here and here.  By presuming that CB build system is slower than make I am not trying to insult codeblocks.  I am just saying that make is currently faster than almost everything else and its a much more mature product and there more likely to be better optimized.

[mandrav]

By presuming that CB build system is slower than make I am not trying to insult codeblocks.

I didn't take it as such
But I happen to know the inner workings of C::B build system really good. I know the exact differences it has with make. The only bottleneck for C::B is the actual logging. It's logging in a wxTextCtrl whatever this means in terms of speed. But even so, I think it's still faster than running make from the command line.

And don't forget: C::B used to use make too. Guess why it was dropped in favor of the new build system (yes, I had run speed tests).

[Game_Ender]

Well on my machine for a full build I get the following:

Full Build:
Make: 8:34
CB: 4:28

Code::Blocks is the winner.  That is awsome, why is CB so fast on the full builds?  Are the auto make files inefficient, it does look like they throw a little more info at the compiler.  Are the auto tools scripts use precompiled headers?  I am going to do incremental builds next.

For these after the full build I changed one line in cbeditor.h, and then built them again.
Incremental:
CB: 3:16
Make: Not Done Yet

[mandrav]

Are the auto make files inefficient, it does look like they throw a little more info at the compiler.  Are the auto tools scripts use precompiled headers?

Yes, they do use precompiled headers (as long as your compiler supports them and you didn't pass --disable-pch in configure).
But, note that the PCH created by C::B cannot be used by make and vice-versa. Maybe you didn't notice it and make didn't use the PCH?

[mandrav]

OK, here are the results:


uname -a
Linux amd64 2.6.12-10-amd64-generic #1 Mon Feb 13 12:14:05 UTC 2006 x86_64 GNU/Linux

Make build:
-----------
make clean
./configure --enable-contrib=no --prefix=/usr
time make

real    9m17.087s
user    6m31.024s
sys     1m19.279s

C::B full rebuild (added "-O2 -ffast-math" in project to match make options):
------------------------------------------------------------------
Process terminated with status 0 (8 minutes, 40 seconds)
0 errors, 19 warnings

C::B full rebuild ("stock" project options):
------------------------------------------------------------------
Process terminated with status 0 (4 minutes, 40 seconds)
0 errors, 8 warnings


As you see, C::B is in fact faster than make but not as much as your tests showed (probably due to the PCH issue I pointed out).

[thomas]

If you're going to test it, just make sure to disable all plugins except the Compiler plugin (CodeCompletion esp. is known to make the build slower).

Your tips amaze me every day anew... :lol:

added "-O2 -ffast-math" in project

Good catch

[Game_Ender]

C::B full rebuild (added "-O2 -ffast-math" in project to match make options):

Didn't watch the compile options close enough to see the differences.

[takeshimiya]

If you're going to test it, just make sure to disable all plugins except the Compiler plugin (CodeCompletion esp. is known to make the build slower).

Your tips amaze me every day anew... :lol:

Taken from Ogre Wiki :wink: http://www.ogre3d.org/wiki/index.php/Building_From_Source#GCC_.26_Code::Blocks

Performance Tip: It is suggested to disable Code::Blocks code completion plugin, before opening the Ogre workspace. This workspace contains ~40 projects which will be parsed.

My own tests shows the same, maybe we are missing something?

Regards,
Takeshi Miya

[thomas]

Well, they were measuring the time to compile Code::Blocks, not Ogre.
This particular project is parsed in well under 10 seconds on an average PC if you have all parsing options turned on (2-3 seconds otherwise). After that, code completion takes zero CPU and is entirely irrelevant.
If you either run a batch build or wait a moment before hitting the gear (which is usually the case anyway), the build takes the exact same time with or without that plugin.

[takeshimiya]

Well, they were measuring the time to compile Code::Blocks, not Ogre.
This particular project is parsed in well under 10 seconds on an average PC if you have all parsing options turned on (2-3 seconds otherwise). After that, code completion takes zero CPU and is entirely irrelevant.
If you either run a batch build or wait a moment before hitting the gear (which is usually the case anyway), the build takes the exact same time with or without that plugin.

Ok, my tests didn't show near the same, but it's because I'm low on RAM, which with CodeCompletion enabled and when parsing a Workspace with more than 1 project, and compiling at the same time rendered the pc in a unuseable state, because of swapping to disk.
This didn't happen with a Workspace with 1 project, neither with CodeCompletion disabled.
Anyways, this was before Rev.2121, I have to test if still happens (don't think so).

So the tale is that to compile the Contribs Workspace I always had to disable the CodeCompletion plugin.
Probably if you have 1GB or more of RAM never noticed any of this.

[thomas]

If you are low on physical memory, then precompiled headers are the first thing you want to turn off.
While precompiling the SDK, gcc can easily eat up 350 megabytes of RAM.

Personally, I'd advise to get more RAM though, it's not like RAM is expensive these days. Every ElCheapo PC from a supermarket has a gigabyte these days.

[takeshimiya]

If you are low on physical memory, then precompiled headers are the first thing you want to turn off.
While precompiling the SDK, gcc can easily eat up 350 megabytes of RAM.

Good to know, trough I had preffer to disable the plugin rather than disabling precomp headers.

Personally, I'd advise to get more RAM though, it's not like RAM is expensive these days. Every ElCheapo PC from a supermarket has a gigabyte these days.

Look, Germany is currently the most cheap (western) country to buy electronic devices. Most things are even more cheap than in USA.
So, keep in mind that in other countries, the word "not expensive" doesn't apply there.

Here, for example, every "ElCheapo" PC from a supermarket has 128 MB these days, and thanks to the monetary and importing differences, it can be even a lot more expensive than what can be 1GB in Germany.

I wanted to buy one stick more, but my motherboard is very conflictive (advice: never buy a mobo with ATI northbridge chipset).

[sethjackson]

You can get 1GB Kingston PC3200 DDR400 at newegg for $77.55 US. You have to pay extra for shipping...

http://www.newegg.com/Product/Product.asp?Item=N82E16820141307

[takeshimiya]

You can get 1GB Kingston PC3200 DDR400 at newegg for $77.55 US. You have to pay extra for shipping...

http://www.newegg.com/Product/Product.asp?Item=N82E16820141307

Thanks, but here $77.55 US isn't the definition of "cheap".
If you account that the currency here is almost 1US$ = 3,10$ (or 1€ = almost 4$), and without accounting shipping, it would be something like ($77.55*3,10)*2, so it would cost $480. And that without accounting shipping.
And here the salaries are simmilar in number (ie. typical salary there is 800US$, and typical salary here is 800$).

Regards,
Takeshi Miya

[sethjackson]

 :lol: I was meaning for us USA ppl Takeshi.

[thomas]

Look, Germany is currently the most cheap (western) country to buy electronic devices. Most things are even more cheap than in USA.

That proves that you have never been anywhere near Germany... :lol:
Hardware is at least 25% more expensive than in the USA.

For example a 512 MB 533 Mhz Kingston DDR2 ValueRAM DIMM costs 59-69 dollars in the USA.
In Germany, the exact same DIMM costs 69-89 Euros. 1 Euro = 1.2 dollars.

Nevertheless, if someone intends to develop software, that's a price one has to pay. You just can't do any serious development on a 128 MB machine, unless your project is entirely trivial. Compilers eat RAM like candy...

[sethjackson]

Compilers eat RAM like candy...

It is a fact of life, but I hate it. 

[Michael]

Compilers eat RAM like candy...

It is a fact of life, but I hate it. 

Or you can try with distributed compilation and so on .

Best wishes,
Michael

[takeshimiya]

Look, Germany is currently the most cheap (western) country to buy electronic devices. Most things are even more cheap than in USA.

That proves that you have never been anywhere near Germany... :lol:
Hardware is at least 25% more expensive than in the USA.

For example a 512 MB 533 Mhz Kingston DDR2 ValueRAM DIMM costs 59-69 dollars in the USA.
In Germany, the exact same DIMM costs 69-89 Euros. 1 Euro = 1.2 dollars.

You're right, no money to go near Germany, but that's from articles I've read and comparisons about electronic devices. Maybe it doesn't applies to computer devices, only electronic devices.

Nevertheless, if someone intends to develop software, that's a price one has to pay. You just can't do any serious development on a 128 MB machine, unless your project is entirely trivial.

BTW, I have 512MB, but after all the MBs eaten by the shared video card, services (apache, mysql, etc), not a lot of ram is left.
So advice: don't buy a motherboard with an ATI chipset. :?