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.
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
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.
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:-
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:-
# -*- 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.
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:-
// 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:-
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..!
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 ): st.Append( CCFLAGS = '-Ox' )
g++ -o libs/sigc++2/sigc++/connection.os -c -g -DARCH_X86 -msse -mfpmath=sse -DUSE_XMMINTRIN
-DBUILD_SSE_OPTIMIZATIONS -Wall -DHAVE_LIBLO -DENABLE_NLS -Woverloaded-virtual -fPIC -Ilibs/sigc++2 libs/sigc++2/sigc++/connection.cc
As you can see, this is to compile the Debug version of connection.cc. There's only one copy of connection.cc on my sysem. I opened up a terminal window and typed that exact same command (except with a different name for the target file). Then I compared the size of my 'manual' compile with the Scons compile. Both object files were absolutely the same size. Next I entered all those parameters into my C::B project, being very careful to ensure that all the preprocessor directives were the same and all the include folders were in the same order.
And yet, the C::B object file is a different size!?! In fact, all the object files come out at a different size. Mostly bigger though occasionally smaller.
I've even checked that I haven't inadvertantly got 2 versions of gcc/g++ on my system (which I haven't). So why on earth are the C::B modules not coming out at the right size?? Could C::B be re-ordering things? Or sending some additional parameters to the compiler that I don't know about?
Is there any way to view what C::B is sending to the compiler, so I can see if there's a difference?
[Edit...] Oops, oBFusCATed - I just noticed your last sentence. I'll try that now...!
gcc -Wall -g -c -msse -mfpmath=sse -Woverloaded-virtual -fPIC -Ilibs/sigc++2 -DARCH_X86 -DUSE_XMMINTRIN -DBUILD_SSE_OPTIMIZATIONS -DHAVE_LIBLO -DENABLE_NLS
-I/opt/gnome/lib/glib-2.0/include -I/media/SHAREDDATA/ardour2/libs/sigc++2 -I/media/SHAREDDATA/ardour2/libs/glibmm2 -I/opt/gnome/include/glib-2.0
-I/media/SHAREDDATA/ardour2/libs/pbd -I/usr/include/libxml2 -I/usr/include -I/media/SHAREDDATA/ardour2/libs
-c /media/SHAREDDATA/ardour2/libs/sigc++2/sigc++/connection.cc -o obj/Debug/sigc++/connection.o
Well, there's one difference immediately obvious.... it's using the wrong compiler!! C::B is compiling ".cc" files, using gcc, whereas Scons is using g++.
Any way to force C::B to use g++ ? It doesn't seem to appear in my list of compiler options.
Suggesting to modify line 561 of cbproject.cpp would do it :wink:
if (ext.IsSameAs(FileFilters::C_EXT) || ext.IsSameAs(FileFilters::CC_EXT))
f->compilerVar = _T("CC");
I haven't actually tried it, but I think that's the right place to fix it in Code::Blocks, and I do think it should be changed. .cc is supposed to be a C++ extension.
In the meanwhile, right click your source file in the Projects tab, click on Properties, go to Advanced and change "Compiler variable:" to "CPP".