[Scons-users] Overriding the default compilation behavior / supporting new compilers

Hi Yanghao,

you can override the environment variable 'CCCOM' to tell scons how your
compiler behaves (based on some condition).

For example:

env = Environment()

env["CC"] = os.getenv("CC") or "gcc"

if env["CC"] == "xyz-cc":
env["CCCOM"] = '$CC -c $CFLAGS $CCFLAGS $_CCCOMCOM $SOURCES'

You can find the documentation of all these CC-something variables here:
http://scons.org/doc/1.0.1/HTML/scons-user/a4754.html
(the example I gave here is more or less copy-pasted from my SConstruct,
which I use to build a arm cortex m4 firmware with arm-none-eabi-gcc &
TI's armcl compiler)

Hope this is what you wanted to know.

Cheers,

Dan

Post by Hua Yanghao
Dear Scons Friends,
I looked at https://bitbucket.org/scons/scons/wiki/ToolsForFools which
is a good starting point explaining how to use scons to implement
tools. However I am missing one part how scons is actually connecting
the CC=xyz-cc to the tools/xyz-cc.py file. For cross-compilation (e.g.
CC=arm-none-eabi-gcc) it just works (I assume it is using the GCC
command line options).
Assume I have a customized C compiler called xyz-cc which uses
completely different command line options to generate object files and
a customized library archiver xyz-ar for building static libraries.
Instead of making a new builder name (e.g. xyzObject(),
xyzStaticLibrary), how can I change the default behaviour of the
Object/StaticLibrary/Program builder to use my customized compilation
tool chain?
Best Regards,
Yanghao
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Hua Yanghao

2017-09-27 15:41:28 UTC

Thanks Dan.

The problem is more with a customized AR command, where the current
implementation inserts an "rc" after ar (e.g. ar rc ....).
I guess I can still override the ARFLAG environment variable instead
of appending to it.

However as there are some default FLAGS in other cases I do not want
to override, so it becomes fragmented as I have to consider every and
each cases and consider if I should append to it or replace and
append. In the end I thought it might be cleaner if I just write an
implementation of this special compiler with generate/exists calls but
I am not successful so far for scons to automatically discover it in
site_scons/site_tools/ folder. e.g. instead of a centrally located
huge if/else I want to split the logic into separate pieces just for
the sake of easier maintenance in the future.

BR, Yanghao

On Wed, Sep 27, 2017 at 5:20 PM, Dan Čermák

Post by Dan ÄermÃ¡k
Hi Yanghao,
you can override the environment variable 'CCCOM' to tell scons how your
compiler behaves (based on some condition).
env = Environment()
env["CC"] = os.getenv("CC") or "gcc"
env["CCCOM"] = '$CC -c $CFLAGS $CCFLAGS $_CCCOMCOM $SOURCES'
http://scons.org/doc/1.0.1/HTML/scons-user/a4754.html
(the example I gave here is more or less copy-pasted from my SConstruct,
which I use to build a arm cortex m4 firmware with arm-none-eabi-gcc &
TI's armcl compiler)
Hope this is what you wanted to know.
Cheers,
Dan

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2017-09-27 16:10:25 UTC

Generally the compiler and linker are implemented as different tools as far
as SCons is concerned.
That said migrating your more complex logic into site_scons/__init__.py and
if appropriate different tools in site_scons/site_tools is wise.

Regardless, if you care compiling C or C++, then basing your tools or
modifications to existing variables would be the simplest way to use your
cross compilers.

Post by Hua Yanghao
Thanks Dan.
The problem is more with a customized AR command, where the current
implementation inserts an "rc" after ar (e.g. ar rc ....).
I guess I can still override the ARFLAG environment variable instead
of appending to it.
However as there are some default FLAGS in other cases I do not want
to override, so it becomes fragmented as I have to consider every and
each cases and consider if I should append to it or replace and
append. In the end I thought it might be cleaner if I just write an
implementation of this special compiler with generate/exists calls but
I am not successful so far for scons to automatically discover it in
site_scons/site_tools/ folder. e.g. instead of a centrally located
huge if/else I want to split the logic into separate pieces just for
the sake of easier maintenance in the future.
BR, Yanghao
On Wed, Sep 27, 2017 at 5:20 PM, Dan ÄermÃ¡k

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Hua Yanghao

2017-09-27 16:30:47 UTC

Thanks Bill.

So how scons actually finds xyz-cc / xyz-ar implementation in Tools or
site_scons/sit_tools/ folder?

Is it based on string matching (e.g. CC=xyz-cc)? I had a try this way
but it is not working for me.

BR, Yanghao

Post by Bill Deegan
Generally the compiler and linker are implemented as different tools as far
as SCons is concerned.
That said migrating your more complex logic into site_scons/__init__.py and
if appropriate different tools in site_scons/site_tools is wise.
Regardless, if you care compiling C or C++, then basing your tools or
modifications to existing variables would be the simplest way to use your
cross compilers.

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2017-09-28 00:52:39 UTC

See the manpage:

Before reading the *SConstruct* file, *scons* looks for a directory named
*site_scons* in various system directories (see below) and the directory
containing the *SConstruct* file; for each of those dirs which exists,
*site_scons* is prepended to sys.path, the file *site_scons/site_init.py*,
is evaluated if it exists, and the directory *site_scons/site_tools* is
prepended to the default toolpath if it exists. See the --no-site-dir and
--site-dir options for more details.

If you have your own tool in site_scons/site_tools and then do
env.Tool('my_special_tool'), and there's my_special_tool.py in site_tools,
it should load it.

Post by Hua Yanghao
Thanks Bill.
So how scons actually finds xyz-cc / xyz-ar implementation in Tools or
site_scons/sit_tools/ folder?
Is it based on string matching (e.g. CC=xyz-cc)? I had a try this way
but it is not working for me.
BR, Yanghao

Post by Bill Deegan
Generally the compiler and linker are implemented as different tools as

far

Post by Bill Deegan
as SCons is concerned.
That said migrating your more complex logic into site_scons/__init__.py

and

Post by Bill Deegan
if appropriate different tools in site_scons/site_tools is wise.
Regardless, if you care compiling C or C++, then basing your tools or
modifications to existing variables would be the simplest way to use your
cross compilers.

Post by Dan ÄermÃ¡k
Hi Yanghao,
you can override the environment variable 'CCCOM' to tell scons how

your

Post by Dan ÄermÃ¡k
compiler behaves (based on some condition).
env = Environment()
env["CC"] = os.getenv("CC") or "gcc"
env["CCCOM"] = '$CC -c $CFLAGS $CCFLAGS $_CCCOMCOM $SOURCES'
You can find the documentation of all these CC-something variables
http://scons.org/doc/1.0.1/HTML/scons-user/a4754.html
(the example I gave here is more or less copy-pasted from my

SConstruct,

Post by Dan ÄermÃ¡k
which I use to build a arm cortex m4 firmware with arm-none-eabi-gcc &
TI's armcl compiler)
Hope this is what you wanted to know.
Cheers,
Dan

Post by Hua Yanghao
Dear Scons Friends,
I looked at https://bitbucket.org/scons/scons/wiki/ToolsForFools

which

Post by Hua Yanghao
is a good starting point explaining how to use scons to implement
tools. However I am missing one part how scons is actually connecting
the CC=xyz-cc to the tools/xyz-cc.py file. For cross-compilation

(e.g.

Post by Hua Yanghao
CC=arm-none-eabi-gcc) it just works (I assume it is using the GCC
command line options).
Assume I have a customized C compiler called xyz-cc which uses
completely different command line options to generate object files

and

Post by Hua Yanghao
a customized library archiver xyz-ar for building static libraries.
Instead of making a new builder name (e.g. xyzObject(),
xyzStaticLibrary), how can I change the default behaviour of the
Object/StaticLibrary/Program builder to use my customized compilation
tool chain?
Best Regards,
Yanghao
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Hua Yanghao

2017-09-28 16:07:25 UTC

Thanks Bill. This works perfectly!

Now I added also some other customized tools in site_scons/site_tools/
folder but there is one more thing: how the xyzCOMSTR is handled?
e.g. I have enabled a new builder called xyz, which is using $XYZCOM
to build the target, but only want to show the $XYZCOMSTR on the
console (unless I switch to verbose mode).

Best Regards,
Yanghao

Before reading the SConstruct file, scons looks for a directory named
site_scons in various system directories (see below) and the directory
containing the SConstruct file; for each of those dirs which exists,
site_scons is prepended to sys.path, the file site_scons/site_init.py, is
evaluated if it exists, and the directory site_scons/site_tools is prepended
to the default toolpath if it exists. See the --no-site-dir and --site-dir
options for more details.
If you have your own tool in site_scons/site_tools and then do
env.Tool('my_special_tool'), and there's my_special_tool.py in site_tools,
it should load it.

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2017-09-28 16:11:19 UTC

Can you pastebin your code for XYZ ?

Post by Hua Yanghao
Thanks Bill. This works perfectly!
Now I added also some other customized tools in site_scons/site_tools/
folder but there is one more thing: how the xyzCOMSTR is handled?
e.g. I have enabled a new builder called xyz, which is using $XYZCOM
to build the target, but only want to show the $XYZCOMSTR on the
console (unless I switch to verbose mode).
Best Regards,
Yanghao

prepended

to the default toolpath if it exists. See the --no-site-dir and

--site-dir

options for more details.
If you have your own tool in site_scons/site_tools and then do
env.Tool('my_special_tool'), and there's my_special_tool.py in

site_tools,

it should load it.

Post by Bill Deegan
Generally the compiler and linker are implemented as different tools

Post by Bill Deegan
far
as SCons is concerned.
That said migrating your more complex logic into

site_scons/__init__.py

Post by Bill Deegan
and
if appropriate different tools in site_scons/site_tools is wise.
Regardless, if you care compiling C or C++, then basing your tools or
modifications to existing variables would be the simplest way to use your
cross compilers.

but

Post by Hua Yanghao
I am not successful so far for scons to automatically discover it in
site_scons/site_tools/ folder. e.g. instead of a centrally located
huge if/else I want to split the logic into separate pieces just for
the sake of easier maintenance in the future.
BR, Yanghao
On Wed, Sep 27, 2017 at 5:20 PM, Dan ÄermÃ¡k

arm-none-eabi-gcc

Post by Dan ÄermÃ¡k
&
TI's armcl compiler)
Hope this is what you wanted to know.
Cheers,
Dan

libraries.

Post by Hua Yanghao
Instead of making a new builder name (e.g. xyzObject(),
xyzStaticLibrary), how can I change the default behaviour of the
Object/StaticLibrary/Program builder to use my customized compilation
tool chain?
Best Regards,
Yanghao
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Hua Yanghao

2017-09-28 16:14:46 UTC