On Saturday, November 9, 2024 at 4:09:05 PM UTC layu... wrote: It is not really clear, but I think you should indeed read it as
The name of the lowest level of the directory [of the Tupfile this flag appears in.] That clarifies it, thank you. More generally, Tup does not accommodate well performing actions in other directories than the current Tupfile. I you want to create a/b/c.out, then the rule should reside in a/b/Tupfile. Not in the top-level Tupfile. All of these, including the directory question, are trying to build assets used by top-level rules. I'm trying to replace GNU Make, and I'm likely hitting a perspective wall. What I'm trying to do is to have a bunch of "styles" or flavors of sources, separated into subdirectories: styles/*style1*/sourcefile.suffix styles/*style2*/sourcefile.suffix and use them to build assets in a different subdirectory. The build tools need to only see one subdirectory at a time, or they get confused. I was trying to remove duplication with something like: foreach styles/*/input.suf | sourcefile |> somecommand --style %g %i |> tmpDir/%d-%B foreach tmpDir/* |> finalprocessor %f %o |> outDir/%g.pdf or using %g in both places on the first line, whatever works. Since globbing on directories isn't supported, and since %d doesn't work like I thought, right now I'm doing this by repeating rules for each style; 6 styles, 6 nearly duplicate rules, differing only by the input (and outputs, since that also has to be hard-coded). I actually have multiple input file types in each style, and each needs its own command, so with 6 styles and two templates (the style sources) in each, I am writing 12 rules which I was hoping to get down to 2. What I'm understanding is that if I want to do something like this, I'll need to create a Tupfile in the styles/ directory, and one in each of the styles with a rule that looks like: *.suf | ../../sourcefile |> somecommand --style %d %i |> ../../tmpDir/%d-%B I'll duplicate each Tupfile to each subdirectory (since the rules are identical), and hope I keep them in sync... although, I suppose I could have a top-level config file, and each Tupfile would just import that top-level config file. The Tupfiles would still be duplicate, but I wouldn't worry about forgetting to copy changes across. Then my top-level Tupfile would contain the same, original rule like: foreach tmpDir/* |> finalprocessor %f %o |> outDir/%g.pdf Is that right? Or is there an easier way to go about this that I'm missing? If you want to generate rules programmatically, you may have to consider lua and other scripting capabilities of Tup. I'm not. I only did that in my examples for reproducability by readers. The Tupfile is hand-coded, and more complex than my minimal examples. -- -- 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 visit https://groups.google.com/d/msgid/tup-users/adb4399c-4e04-495d-85e4-c727ead4070fn%40googlegroups.com.
