On Thursday 01 of October 2015 10:05:17 Mike Shal wrote:
> Hmm, can you give an example here? I don't understand why you'd want to
> have libsomething.a and then a <libsomething.a> group - after all, an
> archive is really just a group of objects :). I'm curious to see how you're
> using it!

First of all the <libsomething.a> group only has one file - libsomething.a - 
and nothing more.

The problem here is that tup doesn't allow me to specify a file as input if it 
was generated in different directory by a different tupfile. The only way 
around that was to use groups.

Here's an example:
1. create some test folder with a/ and b/ subfolders, initialize tup 
repository;
2. place Tupfile.lua in each of them;
3. a/Tupfile.lua generates a file in different, generated, folder:

tup.rule("echo Hello > %o", {"../c/generated.txt"})

4. b/Tupfile tries to read this file:

tup.rule({"../c/generated.txt"}, "cat %f") 

5. See the error:

> $ tup
> [ tup ] [0.000s] Scanning filesystem...
> [ tup ] [0.006s] Reading in new environment variables...
> [ tup ] [0.006s] Parsing Tupfiles...
> 
>  1) [0.001s] a
> 
> * 2) [0.001s] b
> tup error: Unable to use inputs from a generated directory (18) that isn't
> written to by this Tupfile.> 
>  - [18] c
> 
> tup error [string "builtin"]:233: Error while parsing dependent Tupfiles
> 
> stack traceback:
>         [C]: in function 'definerule'
>         [string "builtin"]:233: in function <[string "builtin"]:77>
>         (...tail calls...)
>         [string "Tupfile.lua"]:1: in main chunk
>  
>  [  ] 100%
>  *** tup: 1 job failed.

If you use groups, then the problem is solved. Replace the rules in tupfiles 
with:

tup.rule("echo Hello > %o", {"../c/generated.txt", "../c/<generated.txt>"})

tup.rule({"../c/<generated.txt>"}, "cat %<generated.txt>") 

Actually most of what I've done in my project (the thing I described above) 
wouldn't be needed if there was no such restriction in tup. So I wrote some 
lua code that makes sure that some generated files that are useful in other 
rules (like archives or linker scripts) are also put to a group, and in these 
"other" rules (like linking) I transform real paths to groups so that these 
files could be used.

So I have a function ar(output, ...), which creates the file "output", but 
also puts it in the group that has path and name build out of this "output" 
string.

https://github.com/DISTORTEC/distortos/blob/master/Tuprules.lua#L208

Then I also have link(output, ...) function that parses each element of the 
vararg ("..."), transforms the path to the group and uses that in the rule, 
because you cannot use the file in the "normal" way due to the above error.

https://github.com/DISTORTEC/distortos/blob/master/Tuprules.lua#L228

I actually had to do the same thing with generated headers used as order-only 
inputs - such use also produces a very similar error message, so I used groups 
too.

Building out of the source tree (which is the "root cause" of this error) - 
which you probably don't like - can be justified in many ways. Ease to clean 
the whole project is just one of them. The fact that countless .o files don't 
clutter your view of the source hierarchy is another one. Or the fact that you 
can build multiple variants of the same source (for example for different 
architectures) at the same time.

Or maybe you're asking why I archive objects in my project instead of using 
objects directly? If that's the case, then I'm writing an RTOS for 
microcontrollers, and in most use-cases you don't have to compile the RTOS 
along with your application - all you need are the headers and the archive 
with the whole system functionality.

There are more restrictions like this one in tup - for example the fact that 
you cannot use dot-files or dot-folders as input/output (I've wrote about that 
some time ago).

Regards,
FCh

-- 
-- 
tup-users mailing list
email: tup-users@googlegroups.com
unsubscribe: tup-users+unsubscr...@googlegroups.com
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 tup-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to