Sorry for the delayed response - replies were being sent to spam and I barely caught your most recent reply before deleting.
> You should just be able to use a single group, like $(TUP_CWD)/<libs> that corresponds to the "generate libraries" stage, so all libraries can also list this <libs> group as an output, and all binaries can list the same group as an input. Yep, that was how it was done originally. The actual project is substantially more complex (15 minute build times) than the example given here and we wanted the ability to build small portions of the tree to save time. The actual order dependencies are being generated with lua scripting by iterating over the linker parameters and looking for "-l". > One way it can work now until I get the above issue fixed is to have two separate variables, so that the outputs use $(TUP_CWD) based paths and things like -L use $(TUP_VARIANTDIR) based paths. Something like this patch applied to your example: I tested the patch on the example and it works here as well. I haven't tried expanding it to the full project yet. > 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. > I added this to the manual; let me know if it is insufficient. Thanks! I think this is good. I might try to write some additional instructions for the variant section based on my experience. If so, I'll share it here. Thanks, Christopher -- -- 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/b510987a-b114-49d2-aa19-dce1604de0b2n%40googlegroups.com.
