[Scons-users] Code organization

Managan, Rob managan1 at llnl.gov
Thu Jan 16 16:20:36 EST 2014


I believe that Scons does call the preprocessor. It definitely works for
items added to CPPDEFINES; they get added to the command line and my code
relies on them; at least for things like #ifdef ...

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Rob Managan email managan at llnl.gov
LLNL phone: 925-423-0903
P.O. Box 808, L-095 FAX: 925-422-3389
Livermore, CA 94551-0808





On 1/16/14 1:00 PM, "Dirk Bächle" <tshortik at gmx.de> wrote:


>Hi Russell,

>

>On 16.01.2014 19:11, Russell, J.J. wrote:

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

>

>this looks like you try to "wink in" different trees of include files

>for each target. The Repository() function might be what you're looking

>for, UserGuide, chap. 22, "Building From Code Repositories":

>

> http://www.scons.org/doc/production/HTML/scons-user/c4041.html

>

>Best regards,

>

>Dirk

>

>

>_______________________________________________

>Scons-users mailing list

>Scons-users at scons.org

>http://four.pairlist.net/mailman/listinfo/scons-users




More information about the Scons-users mailing list