On Thu, Sep 23, 2021 at 12:42 AM Christopher Corsi <[email protected]> wrote:
> > If you run this without a variant, you get foo.txt and build/bar.txt as > files. If you run it with a variant called 'objdir', you get objdir/foo.txt > and objdir/build/bar.txt. But if you run it with a variant called 'build', > then you get objdir/foo.txt and objdir/bar.txt since it thinks the second > rule is trying to point into the variant rather than creating a subdir. I > haven't found a way to distinguish between when you're intentionally trying > to put a file into a variant (like your example when using $(LIBS_DIR)), > and when the output dir happens to have the same name as the variant dir. > So I'm not sure how to address this other than to say "don't name a variant > the same as a top-level generated directory" in the manual somewhere. Your > thoughts? Or can you think of a better approach? > > One idea comes to mind but it would be a bit more complex. Right now it > seems like output paths have the variant directory prefix added > unconditionally. The parser could track expansions that started with > $(TUP_VARIANTDIR) (i.e. $(TUP_VARIANTDIR) itself or recursively, some other > variable that started with this). If the output path uses one of these > values it can avoid adding the prefix again. This would be fragile if there > was a use case for including $(TUP_VARIANTDIR) in a path where it wasn't > the first path component but I can't think of a reason why someone might do > that. > > Oh, that's a good idea. Initially I thought it wouldn't work since you could have TUP_VARIANTDIR-based paths and regular paths in the same variable, so tracking which variables are TUP_VARIANTDIR-based would be tricky. Eg: libs = $(TUP_VARIANTDIR)/lib1.a build/lib2.a Presumably we would want lib1.a to be treated as if it's already in a variant, but build/lib2.a to still get put in a variant directory (even if it's also named "build"). But thinking about it some more, I thought it could work if TUP_VARIANTDIR basically expanded to a node variable (not commonly used, but these are like database references during the parsing stage). I updated how node variables work, and now $(TUP_VARIANTDIR) isn't expanded into its full string until later, which means if it's used in an output section, we can know that it is already intending to point into the variant directory. Would you be able to do another test with https://github.com/gittup/tup/tree/variantdir-nodevar and see if you find any issues? I think it resolves the issue pretty nicely, and doesn't rely on string-matching the variant directory or cause problems if a generated directory has the same name as the variant directory. If that solves your use-case I'll merge it in. Thanks for your help, -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]. To view this discussion on the web visit https://groups.google.com/d/msgid/tup-users/CA%2B6x0LUuwJ0DX_RHByzubO6evRNtfHM1OWQVT4PeVM08NqQ7Gg%40mail.gmail.com.
