[Scons-users] 回复： can I have a feature request: do a full buildprocess in the rule collect phase

[Bill Deegan]

Charles,

For your specific usage, how many sip files and how many generated files
are we talking about?

-Bill

On Thu, Sep 10, 2015 at 6:33 PM, 查理王 <75187631 at qq.com> wrote:

> Bill:
>
> Thanks, let's discuss in scons-users at scons.org.
>
> It is absolutely the best idea to use Scanner when possible, but some
> tools do not have this feature and we can not modify it if it is a close
> source product. SIP is not the only example.
>
> We use "scons in scons" when we do not any other way to finish it, or it
> is too trouble to write a scanner of it.
>
> Charles
>
> ------------------ 原始邮件 ------------------
> *发件人:* "Bill Deegan";<bill at baddogconsulting.com>;
> *发送时间:* 2015年9月11日(星期五) 上午9:20
> *收件人:* "SCons users mailing list"<scons-users at scons.org>;
> *主题:* Re: [Scons-users] can I have a feature request: do a full
> buildprocess in the rule collect phase
>
> Charles,
>
> Generally running SCons from SCons (as you suggest) is not a great idea.
> Secondly this message is best sent to the users mailing list and not the
> dev mailing list. (I see you sent it to both).
>
> Ideally the QT tool would include a scanner to process the SIP input
> file(s) and add the expected output file(s) to the DAG.
> If it is not doing that, then the best thing to do would be to add the
> logic to do that.
>
> -Bill
>
> On Thu, Sep 10, 2015 at 4:13 PM, 查理王 <75187631 at qq.com> wrote:
>
>> 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-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150910/21ed02f4/attachment.html>