Yeah, that's exactly what I ended up doing because a script was too much 
hassle for one extra command.  Works great, thanks!

On Thursday, March 8, 2018 at 4:45:16 PM UTC-5, Erik wrote:
>
> Tup executes everything in a shell in fuse and essentially cares only 
> about the final state of the files after running a command. This means that 
> you can do some pre- and post-processing tricks to preserve the dependency 
> graph.  In your specific case, you should be able to take:
>
> : a |> create b |> b
> : b |> modify b |> b
>
> while fails for the reasons discussed, and make it:
>
> : a |> create b && mv b b.tmp |> b.tmp
> : b.tmp |> cp b.tmp b && modify b |> b
>
> giving you what you want and keeping the dependency graph intact.
>
> On Thu, Mar 8, 2018 at 2:43 PM Paul Guenette <[email protected] 
> <javascript:>> wrote:
>
>> You make good points.  I think the easiest thing to do is to create 
>> either a macro or an intermediary script so that the .hex is only generated 
>> once in Tup's eyes, and is properly tracked.  Changing the original script 
>> would be a huge PITA.
>>
>>
>> On Thursday, March 8, 2018 at 10:48:33 AM UTC-5, Ben Boeckel wrote:
>>>
>>> On Thu, Mar 08, 2018 at 07:24:04 -0800, Paul Guenette wrote: 
>>> > The issue is that the script I'm calling edits the .hex file in 
>>> place.  So 
>>> > if I go a->b.tmp, b.tmp -> b.tmp is my only option. 
>>>
>>> Can the script be updated? The problem with modifying in place is that 
>>> you'll never have a clean build; the input file is always newer than the 
>>> command which ran it. Also, how is Tup (or any build tool) to know that 
>>> it shouldn't run the `a -> a` step infinitely? Its input was updated, so 
>>> it should be run again. And so on. 
>>>
>>> I'd recommend fixing the tool to not work in-place. This might mean 
>>> copying the file and then operating on it at the new location. 
>>>
>>> > : ../bld/_bin/$(PROJECT_NAME).map ../bld/_bin/$(PROJECT_NAME).hex |> 
>>> $( 
>>> > API_DIR)/Tools/crc32.exe %f FFFFFFFF 0 |> 
>>> > 
>>> > The above line would also create the correct call, but it throws this 
>>> error: 
>>> > 
>>> > tup error: Unspecified output files - A command is writing to files 
>>> that 
>>> > you didn't specify in the Tupfile. You should add them so tup knows 
>>> what to 
>>> > expect. 
>>>
>>> You can also delete the temp file before the rule exits. 
>>>
>>> --Ben 
>>>
>> -- 
>> -- 
>> tup-users mailing list
>> email: [email protected] <javascript:>
>> unsubscribe: [email protected] <javascript:>
>> options: http://groups.google.com/group/tup-users?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "tup-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
-- 
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to