I understand that Tupfiles are supposed to be independent. That is you
can't guarantee the order in which they are read, and hence the order that
things are added to the database. Within a Tupfile, things are processed
from top to bottom, so generated files added earlier in the Tupfile can be
referenced later in the Tupfile, even though they haven't been generated
yet.
So how do I set up Tupfiles so that I build a shared library in one
directory and link against it in another? The example in the manual on
"multiple directories" has this structure, but it's unclear how this works,
what indeed is guaranteed to work.
So lets say I have a simple hello world program implemented as a shared
library and a main executable.
lib/hello.c:
const char* hello() { return "hello"; }
main/main.c:
#include <stdio.h>
const char* hello();
int main(int argc, char* argv[]) {
printf("%s\n", hello());
return 0;
}
I want to build hello.c into libhello.so and main.c into main, linking with
libhello.so.
So I have (I'm on Linux x86):
lib/Tupfile
: hello.c |> gcc -c -fPIC -o hello.o hello.c |> hello.o
: hello.o |> gcc -shared -o libhello.so hello.o |> libhello.so
main/Tupfile
: main.c |> gcc -c -o main.o main.c |> main.o
: main.o ../lib/libhello.so |> gcc -o main main.o ../lib/libhello.so |>
main
Result of running tup:
[ tup ] [0.012s] Scanning filesystem...
[ tup ] [0.024s] Reading in new environment variables...
[ tup ] [0.045s] Parsing Tupfiles...
1) [0.001s] .
2) [0.003s] lib
3) [0.006s] main
[ ] 100%
[ tup ] [0.058s] No files to delete.
[ tup ] [0.058s] Generating .gitignore files...
[ tup ] [0.096s] Executing Commands...
1) [0.016s] lib: gcc -c -fPIC -o hello.o hello.c
2) [0.024s] main: gcc -c -o main.o main.c
3) [0.020s] lib: gcc -shared -o libhello.so hello.o
4) [0.026s] main: gcc -o main main.o ../xlib/libhello.so
[ ] 100%
[ tup ] [0.171s] Updated.
So this appears to work. Ignore the part about it actual performing the
building. It appears to parse the "lib/Tupfile" before the "main/Tupfile".
Is this coincidence? Since before it's parsed them it can't know that there
is an implicit ordering dependency between then, could it parse them the
other way around, and if it did would it complain that it didn't know what
libhello.so was? Does it parse them twice, once to work out what the
ordering is and once to do it for real?
If I rename the lib directory to xlib, it still does the same (parses xlib
first). If I remove the libhello.so input from main/Tupfile then it appears
to parse main first (I clean out and start from fresh each time). Now maybe
it's doing it in order of modification time, but I've tried touching files
to alter that and it makes no difference. At least I don't think it does.
So my basic question is is my example working by accident, or is this the
supported pattern, in which case, how does it work? I've tried reading the
manual, and tried reading the source code but so I've not found anything
that tells me how this is supposed to work.
Any help clarifying this would be great.
Thanks.
--
--
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.
