On Mon, Sep 27, 2021 at 2:21 AM Mike Shal <[email protected]> wrote: > 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. > > Well I ended up merging this. If you run into any issues with it, let me know!
Thanks, -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%2B6x0LWTmAHrjj65FC%2B22oiJU4g1jnzVX8-UT43krHzBhJUspw%40mail.gmail.com.
