SConstruct (Scons)

[johne53]

I'm led to believe that C::B can be configured to work with Scons. Can anyone tell me how to set this up? Is it via a plugin or something?

[Game_Ender]

You have to set up Code::Blocks to call an external build tool instead of its own compiler system.

[johne53]

One of the thigs that impressed me about the Windows version of Code::Blocks was that I could import an existing Visual C++ project which would instantly create a full project tree within C::B.

Is anything like that available for an existing Scons file - or even a Make file?

[TDragon]

One of the thigs that impressed me about the Windows version of Code::Blocks was that I could import an existing Visual C++ project which would instantly create a full project tree within C::B.

Is anything like that available for an existing Scons file - or even a Make file?

No, not currently. Importing a Scons file is a possibility (though not yet implemented), but importing a Makefile is highly unlikely. Makefiles are so flexible and powerful that there is no standard way of defining them, so it would be very difficult to design a parser that could translate an appropriate C::B project from even a small fraction of Makefiles "in the wild".

[johne53]

Thanks TDragon - looks like I'll have to do it the hard way then...! 

[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

Clean your code with Code::Blocks ¶

    * Find the button that looks like it has two green arrows chasing each other.
    * Click it

[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]

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.

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

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]

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

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

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')))

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()

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()

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..!

[Mad Scientist]

Ok from what I have seen I am going to guess you are using code blocks as your IDE and the msvc++ compiler that is shipped with your version of msvc++, as long as you only have one compiler installed though it wont make much difference.
I doubt it is different in terms of 16 bit or 32 bit as long as you are using the same compiler( scons will default to msvc unless told other wise or if it is not installed ) and havnt defined 16 bit. So I did notice though that you didn't define any build flags with scons except for some extra defines and that could be what is adding to the size as code blocks has some default flags set unless you change them. Example line( add after your first append ):

Code

st.Append( CCFLAGS = '-Ox' )

[johne53]

Thanks for the info. Actually, this is a Linux project and I'm using gcc compiler. Strictly speaking I think I should be using g++ compiler but C::B doesn't offer that as an option. If I specify gcc, will C::B use g++ compiler where appropriate? If not, that could be another reason for the differences.

[killerbot]

gcc will use g++ where appropriate I think

[johne53]

I've had a good look at C::B but I can't see anything obvious for changing the target between 16 bit and 32 bit. I'm assuming that gcc defaults to 32 bit but it would be nice to know if there are any compiler flags for selecting between 16 bit, 32 bit or even 64 bit compilation.

[Auria]

Strictly speaking I think I should be using g++ compiler but C::B doesn't offer that as an option. If I specify gcc, will C::B use g++ compiler where appropriate? If not, that could be another reason for the differences.

AFAIK the trick is more or less that GCC can have 2 meanings:

Gnu Compiler Collection
Gnu C Compiler

In the compiler dialog, GCC means the former, when you build a C program from terminal, GCC means the latter