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] 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.
