Everything about Scons
A few months ago, I encountered an issue with Scons and the SubstInFile2 tool. When it is used in a variant dir, when the emitter is called, the variant dir is not yet populated. Unfortunately, the emitter tries to open the file in the variant dir, so this does not work.
The only thing to do is to use the source node in the emitter instead of the variant node. So line 112:
keys = subst_keys(str(s.srcnode()))
And this is it!
I chose Eclipse as my new Linux IDE, instead of Konqueror + KWrite. The purpose was to be able to launch a SCons build from the IDE, get the errors in a panel and double-clicking on one of them would direct me to the location of the error.
So Eclipse seemed to fit my needs:
So I will know show you two ways of enabling SCons support for Eclipse.
Some times ago, I proposed an optional build for SWIG if the SWIG binary was not found on the system. Here I propose an enhancement, a new library builder that will be registered in the environment env as PythonModule. It takes the same arguments as a classical SharedLibrary, but it does some additional steps :
Starting from Visual Studio 2005, every executable or dynamic library must declare the libraries it uses with a manifest file. This manifest can be embedded in the executable or library, and this is the best way to deal with it.
When using Scons, this embedding does not occur automatically. One has to overload the SharedLibrary builder so that a post-action is made after building the library :
def MSVCSharedLibrary(env, library, sources, **args): cat=env.OriginalSharedLibrary(library, sources, **args) env.AddPostAction(cat, 'mt.exe -nologo -manifest ${TARGET}.manifest -outputresource:$TARGET;2') return cat env['BUILDERS']['OriginalSharedLibrary'] = env['BUILDERS']['SharedLibrary'] env['BUILDERS']['SharedLibrary'] = MSVCSharedLibrary
With this method, the embedding is made for every library, which is handy. The same can be done for the Program builder with the line :
env.AddPostAction(cat, 'mt.exe -nologo -manifest ${TARGET}.manifest -outputresource:$TARGET;1')
I now regularly use Scons as a cross-platform software construction tool. It is easy, written in Python, and I know Python, so no problem learning a new language as for CMake. In some cases when I use SWIG, the target platform does not have the SWIG executable. But when compiling a module, Scons must use this executable, whatever you try to do. In this case, one need to create a new SharedLibrary builder, so that this attribute will determine if SWIG is present or if the generated .c or .cpp files must be used instead.