[Scons-users] Code organization

[Russell, J.J.]

THE PROBLEM
This is a request for some best practices advice on laying out directories for target specific code and not using the preprocessor (which SCONs does not run) within the code to select the proper target specific code.

BACKGROUND
In the cross-development environment we operate within, there is the issue of how to handle target specific C and C++ code.  The two common tactics are

   1) Using the preprocessor #ifdef’s
   2) Using #include’s of the form
           #include “package/target-specific/xx.h”

We discouraged #1, since it just litters the code, rendering it difficult to read and try to confine the target specific stuff to includes.

 For the #include’s we further discourage this construct

        #if defined (TARGET1)
       #  include “package/TARGET1/xx.h”
       #elif defined (TARGET2)
       # include “package/TARGET2/xx.h”
          etc.

in favor of using the stringification of the preprocessor to do something like this

#define QUOTE(_x)  #_x
#define  INCLUDE_FILE(_package, _target, _file) QUOTE(_package/_target/_file)
#include INCLUDE_FILE(PACKAGE, TARGET,  xx.h)

This requires no modification of the actual code when adding a new target, just composing the new include file and feeding in the appropriate definitions of PACKAGE and TARGET from the compile line. It also has the nice property that when adding a new target, since the code has not changed, there is no superfluous rebuilding of the original targets.

NOW THE ISSUE
SCONs by default, does not run the preprocessor, so this technique will not work.  So how can one make this work within the SCONs philosophy? 

The only thing I can think of is to use -I<include-paths> to direct the proper file inclusion, but this is not easy.  We would like to preserve the syntax

     #include “PACKAGE/file.h”
    
This works fine with a directory structure that looks like
     <root>/
        PACKAGE/
            file.h

and a -I of "-I <root>”
    
However, there is no -I for including target specific directories underneath PACKAGE and still preserving the PACKAGE qualifier in the #include file name, which we feel for is necessary to avoid namespace pollution.

The only solution I can think of is inverting the directory structure.

     <root>/
        TARGET1/
           PACKAGE1/
           PACKAGE2/
           etc.
        TARGET2
            PACKAGE1/
            PACKAGE2/

So the -I path is “-I <root>/TARGET1” or "-I <root>/TARGET2".  This works fine for a formal release structure, but not so hot for development where the organization of <root>/PACKAGE/TARGET is more natural. (Then there is the side question of handling all the common stuff, but that is likely easy once this problem is addressed.)

Any suggestions or is this best we can do?

JJRussell