[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