W dniu 2014-07-26 04:14, Mike Shal pisze:
On Fri, Jul 11, 2014 at 5:42 AM, Quibbler <[email protected]
<mailto:[email protected]>> wrote:
-- 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.
If that's any value, I find "foreach" semantics really problematic with
lua parser, but that's not a problem at all, as this rule can be
replaced perfectly with lua's for loop (this example is a bit verbose,
but it is a real-life one (; ):
--- 8< --- 8< --- 8< --- 8< --- 8< ---
-- in Tuprules.tup:
-- get "file specific flags" from table (ASFLAGS, CFLAGS or CXXFLAGS)
for file named filename
function getSpecificFlags(table, filename)
specific_flags = {}
if table[filename] ~= nil then
specific_flags = table[filename]
end
return specific_flags
end
-- compile (C++) file named input
function cxx(input)
specific_flags = getSpecificFlags(CXXFLAGS, input)
output = {OUTPUT .. tup.getrelativedir(TOP) .. '/%B.o',
'$(TOP)/<objects>'}
tup.rule(input, "$(CXX) $(CXXFLAGS) $(specific_flags) -c %f -o %o",
output)
end
-- in global macro-file compile.lua:
for index, filename in ipairs(tup.glob('*.cpp')) do
cxx(filename)
end
-- in individual Tupfile.lua:
CXXFLAGS ["some-file.cpp"] = "-D__USES_TWO_STACKS -D__USES_CXX"
CXXFLAGS += "-DSTM32F407xx"
tup.include(TOP .. "/compile.lua")
--- 8< --- 8< --- 8< --- 8< --- 8< ---
More on that - https://groups.google.com/forum/#!topic/tup-users/G9EELxi-YvQ
So with lua you can actually just drop foreach and no harm will be done
(at least I don't see any for now).
Regards,
FCh
--
--
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.
