User forums > Using Code::Blocks
SConstruct (Scons)
kolku:
I had written up these instructions for use at my job... hope they are helpful.
Setting Up Code::Blocks ¶
* Startup Code::Blocks
* If Code blocks ask you to associate itself with source files make your own decision.
* Click Create a new project from the startup page/window.
* In the resulting dialog select Empty Project
* Hit Go
* In the Folder to create project in: field enter your directory path to the trunk.
o Example: Mine is c:\Code\trunk\
o Make sure the final directory that the *.cbp file ends up in is where you top level SConstruct file is.
* Hit Next
* In the Compiler: pull-down select GNU GCC Compiler
o This requires that MinGW is installed… look at the Install section above.
* Select the Create "Release" configuration
* Hit Finish
* Goto Project ⇒ Properties…
* Select This is a custom Makefile [checkbox]
* Hit OK
* Goto [Menu] Project ⇒ Build options… A dialog appears.
* Select Release from the left pane.
* From the second pull-down select "Make" commands
* Delete the contents of the four lower fields
* In the first field, Build project/target:, insert the following <path to scons.bat>\scons.bat -k -j 2
o On my system <path to scons.bat> is c:\apps\coding\Python\ so the result is c:\apps\coding\Python\scons.bat -k -j 2
o The default location of Python is something like c:\Python24
* Skip the second field (i.e. leave this blank)
* In the 3rd and 4th fields enter <path to scons.bat>\scons.bat -c
Populating a Code::Blocks Project ¶
* Goto Project ⇒ Add files recursively…
* Browse to your /trunk directory, select it and hit OK
* Hit the Wildcard select button
* Enter the following (or whatever makes sense for your project): *.cc;*.hh;*.cpp;*.h;*.c;*.S;*.y;*.yy;*.l;*.ll;*.txt;*.py;*.xml;*.base;*sconstruct;*sconscript
* Alternative to Wildcard select: Just hit the Select All button
* Hit OK
* Hit Yes to clear previous selections.
* Hit OK
* Wait for a second or two while it parses everything
Building with Code::Blocks ¶
* Find the blue button that looks sort of like a gear.
* Click it :D
Clean your code with Code::Blocks ¶
* Find the button that looks like it has two green arrows chasing each other.
* Click it :D
johne53:
Hi Kolku - I'm really sorry but somehow I didn't notice this reply from you. Your instructions sound really interesting though. Just out of interest, do you find any discrepancies when building single individual source files? I haven't tried your instructions yet but I did try compiling some of this project's source files from within C::B. Even though I was using the same compiler, I couldn't get the relevant object files to be anything like the size that they are when compiled via Scons. This kinda put me off going too much further.... :(
I tried messing around with compiler options and preprocessor directives- but my resultant object files were often half (or even twice) the size of the Scons equivalent. Did you find that problem too - and if so, is there a way around it?
Mad Scientist:
--- Quote ---johne53:Even though I was using the same compiler, I couldn't get the relevant object files to be anything like the size that they are when compiled via Scons.
--- End quote ---
Could Code::Blocks be including some of the include files with the single file compile maybe? (check to see if the exe is the same or larger to check)
Also what I found makes it easy is to use a really short makefile the plus side being you can keep the setup the same for codeblocks you just need to select the makefile and have scons in your PATH environment variable.
--- Code: ---All:
scons -ks -j 3
Release:
scons build=release -ks -j 3
Debug:
scons build=debug -ks -j 3
Profile:
scons build=profile -ks -j 3
clean:
scons --clean -k
--- End code ---
For a quick make tut for this short file:
The labels( eg "All:, "Release:" etc etc ) are the build targets and the tabbed( not spaced ) lines are the commands executed for each target. Note the build=____ is handled by the scons script itself not some function of scons. Also the -s option means only script comments and errors are output.
johne53:
--- Quote from: Mad Scientist on July 27, 2007, 04:31:11 pm ---Could Code::Blocks be including some of the include files with the single file compile maybe? (check to see if the exe is the same or larger to check
--- End quote ---
Good suggestion. In this case the target is a shared object (i.e. dynamic library) and no - they're not the same size. The one built with Scons is slightly bigger than mine.
I used nm to print out the contents of each version. They were almost identical - except that the Scons build had these additional lines at the beginning:-
--- Code: ---00007beb t .L39
00007c01 t .L40
00007c1f t .L41
00007c35 t .L42
00007c6a t .L43
00007c9f t .L44
00007d3d t .L50
00007d74 t .L51
00007d9f t .L52
00007dd6 t .L53
00007e09 t .L54
00007e3c t .L55
0000e1a8 d DW.ref.__gxx_personality_v0
--- End code ---
I don't know if that means anything to anyone but it doesn't mean much to me. The actual SConscript file for this project is quite small and looks like this:-
--- Code: ---# -*- python -*-
import os
import os.path
import glob
soundtouch_files = Split("""
AAFilter.cpp
FIFOSampleBuffer.cpp
FIRFilter.cpp
RateTransposer.cpp
SoundTouch.cpp
TDStretch.cpp
mmx_gcc.cpp
cpu_detect_x86_gcc.cpp
""")
Import('env install_prefix')
st = env.Copy()
st.Append(CCFLAGS="-DHAVE_CONFIG_H -D_REENTRANT -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE")
libst = st.SharedLibrary('soundtouch', soundtouch_files)
Default(libst)
env.Alias('install', env.Install(os.path.join(install_prefix, env['LIBDIR'], 'ardour2'), libst))
env.Alias('tarball', env.Distribute (env['DISTTREE'],
[ 'SConscript'] + soundtouch_files + glob.glob('*.h')))
--- End code ---
I'm not sure what the various import lines do - but I'm guessing that they're probably responsible for the extra code.
johne53:
This morning I had a flash of inspiration.... I realised that it's possible for nm to produce a more detailed output - including the size of each entry in the lib or shared object. Here's a small section, firstly from my compiled target:-
--- Code: ---// My target !
00008736 000003d9 T soundtouch::SoundTouch::putSamples(float const*, unsigned int)
000084e0 00000169 T soundtouch::SoundTouch::setSetting(unsigned int, unsigned int)
00008e5e 0000014f T soundtouch::SoundTouch::setChannels(unsigned int)
00008356 0000000a T soundtouch::SoundTouch::getVersionId()
--- End code ---
and now, the same section from the target built by Scons:-
--- Code: ---Scons target !
00007fa0 00000421 T soundtouch::SoundTouch::putSamples(float const*, unsigned int)
00007ce4 0000019d T soundtouch::SoundTouch::setSetting(unsigned int, unsigned int)
000087d8 00000152 T soundtouch::SoundTouch::setChannels(unsigned int)
00007b22 0000000a T soundtouch::SoundTouch::getVersionId()
--- End code ---
The second column is (I believe) the number of bytes taken up by each function. Note that for all the functions that accept ints, the Scons version is always a bit larger than mine. I'm only guessing here - but is there a chance that this is down to 'int' sizes? Maybe my version's producing 16-bit ints whereas the Scons build is producing 32-bit (or maybe mine's producing 32-bit and Scons uses 64-bit, although that's unlikely). Another possibility is that mine's being compiled to use char-based strings whereas the Scons version maybe used Unicode strings.
Are there any settings within C:B to vary things like this? It's only a gut feeling but it feels very likely to me..!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version