On Wed, Aug 13, 2014 at 9:37 PM, Mike Shal <[email protected]> wrote: > On Mon, Aug 4, 2014 at 4:36 AM, Quibbler <[email protected]> wrote: > >> The manual states that files that are included are relative to the file >> containing the include directive. One might expect that same principle to >> apply to Tuprules.tup but it does not appear to apply. Given a project >> containing a source directory src, subdirectories such as src/A/B/C, and a >> variant directory var, one would expect to find a Tuprules.tup file in the >> root of the project (in the parent of src and var). Now if there is a >> common tup file in src/tup/common.tup, the Tupfile in src/A/B/C might >> include it with "include src/tup/common.tup". >> >> The problem arises when there is a Tuprules.tup file in src/A or >> src/A/B. When the Tupfile in src/A/B/C includes src/tup/common.tup, the >> include_rules directive in src/tup/common.tup should look for Tuprules.tup >> files in all intervening directories such as src, src/A, src/A/B, and >> src/A/B/C. According to the manual It is indeterminate whether it should >> also check the directories about src/tup/common.tup, but I opine that it >> should not. >> >> The problem is that it does not perform the checks above the including >> file, but does perform the checks above the included file. >> >> It appears to me that this is a bug. The include_rules search should use >> the directory context of the include directive. But as of 0.7.1-7-g99f3c3c >> it does not. >> >> > Hi Lee, > > Just to reiterate to make sure I understand correctly: > > You have src/A/B/C/Tupfile with something like: > > include ../../../tup/common.tup > > And a src/tup/common.tup with: > include_rules > (other common things here) > > And you are expecting the "include_rules" to include: > > ./Tuprules.tup > src/Tuprules.tup > src/A/Tuprules.tup > src/A/B/Tuprules.tup > src/A/B/C/Tuprules.tup >
Yes. Because that is the way include works. If include_rules does not work that way then the difference should be carefully described on the documentation. > > But instead you find that it includes: > > ./Tuprules.tup > src/Tuprules.tup > src/tup/Tuprules.tup > > Is that right? > That is my understanding. The anticipated usage of include_rules is that it would be used in Tupfiles > (generally as the first line), not in included files. > That anticipation is part of the problem. In fact I believe it to be counter to reality. The immediate resolution of expressions means that if I put include rules first, and then have settings in the shared or unshared tupfile that tweak the tuprules.tup settings, they will not affect any non-! symbols assigned within tuprules.tup that use the tweaked definitions. So each tupfile has to know what tuprules.tup symbol needs to be tweaked too because it refers to something that needs to be tweaked. In fact the tweaking Tupfile may have to repeat the entire symbol definition. That is bad design. For example, some symbols, such as CPPFLAGS can have dozens of options. My cppflags.tup file for GCC contains 202 lines of text. About 15% of those are comments, so about 170 lines of option settings that I have no interest in repeating in a subordinate Tupfile. So I define the tweaks, such as ROOT in each Tupfile, often by including a common.tup, and then included the tuprules.tup file with include_rules, either in the individual Tupfile, or in the common.tup file. > (In fact, the Lua parser makes this the default and automatically does the > equivalent of include_rules when using Tupfile.lua). > That is one of the reasons I have been avoiding the lua parser. > I believe include_rules was actually broken for included files, but Doug > fixed it with t2102 (see commit df6d6bded). > > Although including another file that does an include_rules is a bit > awkward, I think the current approach does make some sense, since it means > that it means the included file (common.tup) has access to the same > Tuprules.tup files no matter where it is included from. > I can see the value of the perspective that makes the common.tup file invariant. Can you see the value of the perspective that makes the common.tup file context sensitive? Obviously I prefer the latter because it is consistent with the include directive and the whole concept of sub-directory trees inheriting from their parent directories rather than from some central master file. >From the description of your problem, I'd guess you're trying to avoid > having "include_rules" in each Tupfile and instead put it in the common > one, is that right? > Yes. In fact most of my Tupfiles have no content other than including the common or shared tup file. > Unfortunately including them automatically wasn't the default behavior > from the start, but since it was pretty much standard to have > "include_rules" as the first line of every Tupfile, that's why the Lua > parser now does it by default. > Why is that the standard? It appears to complicate the situation, especially WRT immediate evaluation of expressions. > Hope this at least sheds some light on your question > It does, thank you. > - let me know if I misunderstood. > You did not misunderstand the problem I have. However, I disagree with you about the most useful interpretation/omplementation of include_rules. Permit me to suggest an alternate include directive: "include _ancestor <fname>". This directive would act just like include, but without requiring a path prefix on the file name. It would look upward with the directory tree, starting at the CWD and ending at the project root, for a file matching <fname> and include it. Then it would stop. Of course that ancestral file could also "include_ancestor <fname>", where the second <fname> might or might not match the first <fname>. If the include_ancestor directives appear at the top of the tupfiles or their inclusions you would get a situation wherein the parental files were not sensitive to the settings in the files referencing them. But if the include_ancestor directives appeared at the bottom of the tupfiles or their inclusions then you would get a situation wherein the parental files were completely sensitive to the settings in the files referencing them. By following the path upward from the initial Tupfile rather then upward from the file performing the include_ancestor consistency between the include directive and the include_ancestor directive would be maintained. Food for thought. -- -- 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.
