[Scons-users] interrupted or failed build action handling

Bill Deegan bill at baddogconsulting.com
Fri May 1 11:04:19 EDT 2020


So you have 3 commands you always want to run together right?
some pre command, link the program, some post command

Is that correct?

On Thu, Apr 30, 2020 at 10:17 PM daggs <daggs at gmx.com> wrote:

> Greetings Bill.
>
> if you refer to the scons build files, it is a mixture of both env.Command
> and env.Program
>
> Dagg.
>
> *Sent:* Thursday, April 30, 2020 at 8:03 PM
> *From:* "Bill Deegan" <bill at baddogconsulting.com>
> *To:* "SCons users mailing list" <scons-users at scons.org>
> *Subject:* Re: [Scons-users] interrupted or failed build action handling
> You didn't answer my question..
>
>> From the above it sounds like you really have one
>> env.Command(target,source,[pre, doit, post ] ) ?
>>
>
>
> On Thu, Apr 30, 2020 at 8:39 AM daggs <daggs at gmx.com> wrote:
>
>> Greetings Bill,
>>
>> you are correct about the blank source, I don't think I'll use one, I'll
>> check the code, can't remember.
>> the prep verifies inside if the all is ready and if not, it will delete
>> it and rebuild it.
>> I don't mind running prep all the time even if it means it will run
>> unneededly.
>>
>> as I thought of using two env.Command which are depenednet on each other.
>> e.g. prep = env.Command(...)
>> bind = env.Command(...)
>> Depends(bind, prep)
>>
>> am I doing something wrong?
>>
>> Dagg.
>>
>> *Sent:* Thursday, April 30, 2020 at 12:09 AM
>> *From:* "Bill Deegan" <bill at baddogconsulting.com>
>> *To:* "SCons users mailing list" <scons-users at scons.org>
>> *Subject:* Re: [Scons-users] interrupted or failed build action handling
>> Dagg,
>>
>> You should almost never have a blank source. That's a good indicator that
>> you're doing something wrong.
>> How would any build system know when to rebuild?
>>
>> From the above it sounds like you really have one
>> env.Command(target,source,[pre, doit, post ] ) ?
>>
>> -Bill
>>
>> On Wed, Apr 29, 2020 at 12:36 PM daggs <daggs at gmx.com> wrote:
>>
>>> I'll try to create one.
>>>
>>> Dagg.
>>>
>>> *Sent:* Wednesday, April 29, 2020 at 10:09 PM
>>> *From:* "Bill Deegan" <bill at baddogconsulting.com>
>>> *To:* "SCons users mailing list" <scons-users at scons.org>
>>> *Subject:* Re: [Scons-users] interrupted or failed build action handling
>>> Dagg,
>>>
>>> Can you make a simple complete example of what you're trying to do and
>>> post it on github, or pastebin it somewhere?
>>>
>>> _Bill
>>>
>>> On Wed, Apr 29, 2020 at 12:08 PM Bill Deegan <bill at baddogconsulting.com>
>>> wrote:
>>>
>>>> Dagg,
>>>>
>>>> You can't have actions depend on each other.
>>>> Do you mean builders?
>>>>
>>>> -Bill
>>>>
>>>> On Wed, Apr 29, 2020 at 12:02 PM daggs <daggs at gmx.com> wrote:
>>>>
>>>>> Greetings Mats,
>>>>>
>>>>> > Sent: Wednesday, April 29, 2020 at 9:34 PM
>>>>> > From: "Mats Wichmann" <mats at wichmann.us>
>>>>> > To: scons-users at scons.org
>>>>> > Subject: Re: [Scons-users] interrupted or failed build action
>>>>> handling
>>>>> >
>>>>> > On 4/29/20 12:22 PM, daggs wrote:
>>>>> > > Greetings Bill,
>>>>> > >
>>>>> > > you are correct, I'll clarify.
>>>>> > > I have an existing scons env that builds a product.
>>>>> > > I have a bash script that has three funcs, prep, bind and unbind.
>>>>> > >
>>>>> > > I want to do the following:
>>>>> > > prep => bind => build product => unbind.
>>>>> > > when no matter how the build ends (success, failure or user
>>>>> > > interruption), unbind will be called.
>>>>> > > I thought adding prep as action, bind as another action which is
>>>>> > > depended on prep and set bind as depdency of the first action of
>>>>> the build.
>>>>> > > to warp it up, I thought of registering the unbind as an atexit
>>>>> handler
>>>>> > > and register the it to sigterm and sigint too.
>>>>> > >
>>>>> > > I wondered if there is a more elegant way to do it.
>>>>> >
>>>>> > This you should be able to do at the shell level, to keep it simple.
>>>>> >
>>>>> > scons should have exit codes you can use to decide what to do if the
>>>>> > build fails - it will return 0 on success, non-zero on fail.
>>>>> >
>>>>> > For example, trivial SConstruct which tries to build from a source
>>>>> file
>>>>> > which doesn't exist:
>>>>> >
>>>>> > $ scons-3 -f scons-bad.py
>>>>> > scons: Reading SConscript files ...
>>>>> > scons: done reading SConscript files.
>>>>> > scons: Building targets ...
>>>>> > scons: *** [foo.o] Source `foo.c' not found, needed by target
>>>>> `foo.o'.
>>>>> > scons: building terminated because of errors.
>>>>> > $ echo $?
>>>>> > 2
>>>>> >
>>>>> >
>>>>> > Does this help?
>>>>>
>>>>> I'd rather not have a wrapper func, I got to much smartasses in my
>>>>> company that will not use it or use it wrongly.
>>>>>
>>>>> Dagg.
>>>>> _______________________________________________
>>>>> 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
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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/20200501/7ae1f749/attachment.html>


More information about the Scons-users mailing list