Sorry for the late reply!
On 12/10/2014 01:51 AM, Alkis Evlogimenos wrote:
Thanks Rendaw for taking the time to reply.
Here's the code for my functions if it helps:
local function target(name)
return '<' .. name .. '>'
end
local function cc_obj(src)
out = '%B.o'
return tup.rule(src, '^ CXX %f^ $(CXX) -c %f -o %o $(CXXFLAGS)
-I$(TOP)', out)
end
function cc_lib(args)
outs = {
'lib' .. args.name .. '.a',
target(args.name)
}
inputs = {}
for i,v in ipairs(args.srcs) do inputs += cc_obj(v) end
return tup.rule(inputs, '^ AR %o^ $(AR) crs %o %f', outs)
end
function cc_bin(args)
outs = {
args.name,
target(args.name)
}
inputs = {}
for i,v in ipairs(args.srcs) do inputs += cc_obj(v) end
for i,v in ipairs(args.libs) do inputs += v end
return tup.rule(inputs, '^ LINK %B^ $(CXX) %f -o %o', outs)
end
A question to your original suggestion (include deps in the return
object): how can I access lua objects from other Tupfile.lua's? If for
example I have the following structure:
src
- lib
- bin
Can a Tupfile.lua under src/bin access lua objects in a Tupfile.lua
under src/lib? If so how?
I didn't realize you were using <bins>, which makes things a bit more
complicated (I don't know if there's a way to do it with bins). If
you're explicitly naming immediate dependencies though (which is what
I'm doing), you might not need it.
What I'm doing is something like:
1. Instead of returning a '<bin>' string, I return a lua table with
something like {objects = {'ob1.o', 'ob2.o'}, static_libs = {'lib1.a'}}
(I'll call that an augmented path).
2. I modified cc_lib, cc_bin (or at least, my equivalents) to do
tup.definerule if the file directory == the directory tup is currently
parsing (let's call these primary vs secondary Tupfiles).
3. I include ../src/lib/Tupfile.lua from src/bin/Tupfile.lua
(../src/lib/Tupfile.lua won't do tup.definerules because of point 2.)
4. cc_lib and cc_bin should also accept augmented paths as arguments.
This has worked very well for me, with a couple notes:
1. You'll have to write something to determine if the current file is a
primary or secondary Tupfile - I did this by wrapping tup.include in
Tuprules.lua, setting a flag before the inner call to tup.include, and
unsetting it after.
2. You'll also probably have to make your augmented paths contain
filenames relative to the project root, then do further qualification
when you actually call tup.definerule. IIRC there's a get_relative_path
or something that may help here, I don't think it was merged when I
wrote my qualifier. I should probably look into this sometime.
3. If you do a lot of globbing in included Tupfiles, parsing will slow
down. If you don't need the glob to determine the output, try to omit
it using the primary/secondary flag. This doesn't affect rebuilds with
no change in filesystem structure, of course.
4. The augmented path table probably needs some auxiliary methods for
combining with other paths and converting to a string.
Sorry if this is a bit abstract, I might be able to put together a small
example if you think that would help. My own Tup/lua code has lots of
specific use-case stuff so it's not super clean (and there's some unused
bits, parts that need updating, etc).
Also, I realize it's a fair amount of work. I've used my wrapper in a
bunch of projects, so the excessive amount of time I spent fooling
around with my common tup/lua code was worth it I think.
--
--
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.
