Hi Mike, Could you please give an example for using "generate source file" as input file from a different directory than the current compilation via groups?
I've been having tough time implementing this with Lua parser. My source code is generated by the RMI compiler in directory cpp/aam/dm/management/idl/ My compilation runs in axcsw/src/aam/dm/management/rndsettings, but this has to use the IDL generated source file from the above directory, plus, some source files found in this source directory. I've a feeling that Tup has a bug in this feature, as it is failing to recognize %<group_name> where my <group_name> is a group from a different dir. I've built tup from master as of today. Regards, venkrao On Wednesday, 11 June 2014 20:31:02 UTC+5:30, [email protected] wrote: > > On Tue, Jun 10, 2014 at 1:25 PM, Michael Levine <[email protected] > <javascript:>> wrote: > >> >> >> On Tuesday, June 10, 2014 11:43:22 AM UTC-4, [email protected] wrote: >>> >>> >>> I think the issue is with these if statements: >>> >>> if (#objects) then >>> >>> When there are no objects, #objects is 0, and if(0) is true in Lua >>> (unlike in C, where it would be false). So you probably want: >>> >>> if (#objects != 0) >>> >>> or: >>> >>> if (next(objects) != nil) >>> >>> My understanding is the latter is a little more efficient (though I >>> haven't confirmed it :), but that probably only matters if you have >>> extremely large tables. >>> >>> -Mike >>> >> >> >> Thanks Mike -- >> I got similar advice from Rendaw in a PM, and I'm pleased to say that >> this worked just great. >> >> The problem now is one that Rendaw mentioned in his PM to me earlier-- >> the legacy parser had a concept of groups, which I was using to collect >> all of my outputs together, for use in rules. I have made -- what is >> clearly -- an erroneous assumptions that the variables declared in my >> Tupfiles are global variables -- i.e. if I have a table shared_libs which I >> append in each directory, then I'd expect that the shared_libs table would >> be made available for use (containing all of the libs) in my main >> Tupfile.lua. I can work around this by changing my rules to output these >> files into a known path and then find them with a glob rule, but I don't >> like that approach at all. >> > >> Is there a way to have a global variable which is shared with all of the >> Tupfile instances (similar to legacy groups??) Is there any other way to >> achieve this? >> >> > Groups should still be the correct way to handle this. I just pushed a > simple patch to fix them with the Lua parser - they weren't handled > correctly in a few cases (notably when using '%f' and the like). Can you > pull the latest and give it a try in the Lua parser and see if it helps? Eg: > > tup.foreach_rule('*.c', 'gcc -c %f -o %o', {'%B.o', '<objs>'}) > tup.rule('<objs>', 'gcc %<objs> -o %o', 'prog') > > It's a bit crude since you still use the '<objs>' notation as in the > Tupfile parser. Perhaps a more Lua-ized version would look something like: > > tup.foreach_rule(... '%B.o', output_group='objs') > > or something. Maybe Rendaw has some thoughts there :) > > Thanks, > -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.
