Ah, now I understand. While in most cases I think that specifying the output is fine, I'm sure there are naive tools out there that someone will want to use that won't let you specify an output path. Naive tools notwithstanding, it would also be very surprising / confusing for users when something basic-looking like : |> touch foo.txt |> foo.txt suddenly doesn't work with variants.
I think having the non-parallel build/move path as a fallback is a good solution. Tup could emit a warning, something to the effect of, "WARN: <quote rule>, Rules with fixed output paths cannot build variants in parallel. To allow parallel builds, specify the output using %o in the rule, or explicitly using $(TUP_VARIANTDIR)/output_file" On Thu, Dec 10, 2015 at 10:52 AM Mike Shal <[email protected]> wrote: > On Wed, Dec 9, 2015 at 9:33 PM, Pat Pannuto <[email protected]> wrote: > >> >> I had a little less success with this. >> >> I'm trying to build >> https://github.com/lab11/M-ulator/tree/master/simulator >> >> When I used the explicit-variant branch, the first complaint tup had came >> from this Tupfile: >> https://github.com/lab11/M-ulator/blob/master/simulator/cpu/common/private_peripheral_bus/Tupfile#L3 >> >> It said that the ppb.c and ppb.h files were unspecified output files, >> which I fixed by changing the output of that rule to: >> >> : gen_registers.py | exceptions *.conf |> python %f *.conf |> >> $(TUP_VARIANTDIR)/ppb.c $(TUP_VARIANTDIR)/ppb.h >> >> Next it identified that the explicitly name file ppb.h was scheduled to >> be deleted, easy fix, change the next line to: >> >> : ppb.c | $(TUP_VARIANTDIR)/ppb.h |> !cc |> %B.o ../../../<objs> >> >> Next, it had the same complaint about this Tupfile: >> https://github.com/lab11/M-ulator/blob/master/simulator/cpu/Tupfile#L3 >> >> That is, that common/private_peripheral_bus/ppb.h was scheduled to be >> deleted. So I changed that rule to >> >> : foreach *.c | $(TUP_VARIANTDIR)/common/private_peripheral_bus/ppb.h |> >> !cc |> %B.o ../<objs> >> >> Unfortunately, that gave: >> >> tup error: Unable to use inputs from a generated directory (1899) that >> isn't written to by this Tupfile. >> >> >> I'm not really sure how to reconcile this? >> >> I thought it was a little bit weird that I had to specify TUP_VARIANTDIR >> on the outputs at all, felt like something that tup should've been able to >> figure out. >> >> > Right, you shouldn't need to use TUP_VARIANTDIR in either the input or > output list. However, the command needs to either use TUP_VARIANTDIR or the > %-flags in some way in order for tup to communicate where the output file > should go. Here's a simple example: > > # Tupfile A > : |> touch foo.txt |> foo.txt > > # Tupfile B > : |> touch %o |> foo.txt > > Tupfile A won't work with the explicit-variants, since all commands run in > the source directory, so 'touch foo.txt' creates foo.txt in the source dir > instead of the variant dir. In Tupfile B, the '%o' flag is expanded to > something like 'build/foo.txt', so the file is written inside the variant. > You could also do: > > : |> touch $(TUP_VARIANT)/foo.txt |> foo.txt > > But that looks strange IMO. TUP_VARIANTDIR is still needed in some cases, > such as for -I flags: > > : |> generate.py %o |> foo.h > : foreach *.c | foo.h |> gcc -c %f -o %o -I$(TUP_VARIANTDIR) |> %B.o > > This would add something like '-I../../build/sub/dir' so that it could > find the generated foo.h (without a variant, TUP_VARIANTDIR is like > TUP_CWD). > > In your case, you'll need to pass something in to gen_registers.py to tell > it where to write the files. I've attached a patch as an example that > should work with explicit variants. > > Though now that I'm writing this, maybe it makes sense to have explicit > variants assume that the outputs will be written in the srcdir, and then > just move them to the variant directory? So it'd be something like: > > python gen_registers.py *.conf > (writes ppb.h and ppb.c as normal) > mv ppb.c > ../../../../build/simulator/cpu/common/private_peripheral_bus/ppb.c > mv ppb.h > ../../../../build/simulator/cpu/common/private_peripheral_bus/ppb.h > > But that would mean variants couldn't be built in parallel easily on all > platforms. > > -Mike > > -- > -- > 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. > -- -- 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.
