On Thu, Dec 10, 2015 at 11:14 AM, Pat Pannuto <[email protected]> wrote:
> 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" > > Thinking about this some more, would tools be likely to break if they output foo.o, but then tup moves the file to build/foo.o after the fact? I'd like to implement the generate & move function since I think it would work more out-of-the-box as compared to having to use %o everywhere, but I'd hate to be in the same position with broken gdb (or other tools) afterwards. -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.
