On Fri, Jul 11, 2014 at 5:42 AM, Quibbler <[email protected]> wrote:
> However, while I am on the topic of my lack of comprehension, I have been > unable to make sense of the the following message: "tup error: Explicitly > named file '<path>/<file>.o' can't be listed as an input because it was > generated from external directory '<path>/<subdir>' - try placing the file > in a group instead and using the group as an input." > > As written the above message appears to be nonsense -- it is certainly > possible for a rule in a tup file to produce a file that another rule in > another tup file consumes. After all that is kind of the point of > multi-directory build systems. So the message must mean something that I > cannot fathom. Several definitions need to be inferred: > -- Does the term "explicitly name file" suggest that an implicitly named > file would be acceptable where an explicit file name would not? > Sorry I don't have hard definitions for these things. I think "explicit" here just means "something you typed in a Tupfile", rather than an implicit dependency, which would be one that is picked up automatically using the dependency detection mechanism (FUSE/shared library shim, etc). > -- Does the term "external directory" mean something special other than > "not the directory containing the offending rule and tup file"? > As you may know, support for writing to a file in a directory other than the current directory of the Tupfile is fairly new. So with a Tupfile like this: foo/Tupfile: : |> ... |> ../bar/output.o The file bar/output.o is generated from an external directory (ie: not bar/Tupfile, but somewhere else). The problem I ran into while implementing support for that is how to reconcile it with the fact that tup parses the Tupfiles once, and straight through. In particular, this poses a problem with wildcards. Consider if we had a Tupfile like this: Tupfile: : |> auto-gen a C file |> autogen.c : foreach *.c |> gcc ... |> When expanding the *.c wildcard in the second rule, note that we can't rely on the file-system to list all of the .c files, since one of them is generated by another rule. Ie: the first time this Tupfile is parsed, autogen.c hasn't been generated yet. So the way tup knows to create a gcc rule to compile autogen.c is by expanding the wildcard using the tup database rather than the file-system. By the time the second rule is parsed, the autogen.c file will already be present in the database, even though it hasn't actually been created yet. If we introduce another Tupfile in the mix, it gets more complicated: foo/Tupfile: : |> auto-gen a C file |> ../bar/autogen.c bar/Tupfile: : foreach *.c |> ... |> If foo/Tupfile is parsed first, then autogen.c is in the database and the wildcard will work as you'd expect. But if bar/Tupfile is parsed first, how do we know that we should wait until foo/Tupfile is parsed? I realize that sounds a bit silly, but the way Tupfile parser was originally written assuming that each Tupfile would only output to the current directory, and it would be parsed once in order. Once those assumptions were broken, things didn't fit together as nicely. I tried to support this better by making wildcards actually use groups behind the scenes so that Tupfiles could be parsed in any order, but a foreach rule with a wildcard is still tricky to handle. That might be a way to move forward and skip all of those restrictions, though. > -- How do I use a group as an input to the ar command? > You can have multiple Tupfiles that write to the same group: foo/Tupfile: : foreach *.c |> cc ... |> %B.o ../<objs> bar/Tupfile: : foreach *.c |> cc ... |> %B.o ../<objs> ./Tupfile: : <objs> |> ar crs %o %<objs> |> libmystuff.a Note that the <objs> group is anchored in the tree - so this would be a good use for a $(TUP_CWD) variable. You could have: Tuprules.tup: MY_ROOT = $(TUP_CWD) And then the compilation rules can write to $(MY_ROOT)/<objs> (assuming you wanted one <objs> group at the root of your project). > > On this topic I am trying to figure out what is wrong with one tup file > generating an output that is used an an input in a tup file in a different > directory. What is the real problem here? What is it about groups what > works where explicit file naming cannot work? > > As mentioned above, it's primarily about wildcard support. I think we should be able to support individually named files even without supporting wildcards, though. If we have something like this: foo/Tupfile: : |> |> ../bar/output.txt bar/Tupfile: : output.txt |> |> ... If we parse bar first, we can always add a placeholder for 'output.txt' even if we haven't parsed anything that writes it yet. That's not how tup was initially written, but I don't see why we couldn't support that at least now. Though it would still be weird if you could use output.txt explicitly, but *.txt wouldn't catch it. -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.
