Ok, Sorry for such late answer,

Yeah that basically helped. I rewrited rules but still managing bigger 
project is somewhat painfull without synchronizations decriptors.
However without dubt, in comparision to other buildsystems, tup covering 
the most of what I need.
Thanks guys for help, and keep up the good work :)

W dniu piątek, 15 kwietnia 2016 10:36:37 UTC+2 użytkownik Freddie Chopin 
napisał:
>
> On czw, 2016-04-14 at 16:19 -0700, Mateusz Matejuk wrote: 
> > but this is preatty  weak solution since for more such targets i will 
> > need to copy-paste them with exact names, 
>
> But you will have to list the names somewhere anyway... What difference 
> does it make if you say "do.o" instead of "$(ROOT)/<do.o>"? The group 
> can have just one file, and you can expand it in the rule like this: 
>
> : $(ROOT)/<do.o> |> cp %<do.o> do.d |> $(ROOT)/B/do.d 
>
> > Is there any viable method to describe dependency on another rule, 
> > target or goal? 
>
> If you would "invert" your setup it would work without groups. You just 
> need to generate the file do.o in the same directory as the tupfile, 
> and then you can have it as input in another tupfile with full path. 
> Sth like: 
>
> : $(ROOT)/A/do.o |> ar -rcs %o %f |> libdo.a 
>
> Another method - if you really want the file do.o to be in B folder - 
> is to generate it with the tupfile in B, not the one in A. 
>
> 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.

Reply via email to