hi~ all:
As I know, the whole build process of scons consist of:
1, run the SConstruct and its SConscript to collect the build rules.
2, analyse the depencies to determine which actions have to be done.
3, do the selected actions with dependency restrict.
We should not include a long time calculate in the first phase(rule collection)
because to avoid unnecessary long time action is the purpose of the use of
scons and other building tools. But it will trap us when we have to build the
rules by the result of some special long time and complex action.
For example, the SIP provided by Qt, one .sip can generate many files (named by
sip_*.cc and sip*.h). all of the generated files have to be built and linked
into the output program. In practice, SIP is a long time and complex process
that we need to avoid the unnecessary run of it.
The resolution of us is call another scons process by os.system in the first
phase by os.system('scons -f SConstruct.SIP') and then env.Program('tester',
['main.cpp'] + glob('sip_*.c'')).
We believe that this is a common way to resolve this kind of problem, but the
os.system('scons -f ...') is to urgly and if we can encapsulate the whole build
process into a class, then the environment and some other variables can be
shared in main and sub build process. And the user will not be confused to see
multiple scons running prompt in a single scons command.
The source of /usr/bin/scons and /usr/lib/scons/SCons/Script are checked,
unlike the other part of scons which is in highly objective way, these part of
work is not encapsulated into class yet. If these code can be encapsulated and
provided into SConstruct runtime environment, it should be an important
enhancement of scons.
Thanks very much.
Charles._______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
