Hi,
I am trying to convert my pre-explicit variant project Tupfiles and running into a problem.
Currently there are two basic stages in the build: Generate libraries, then generate binaries that link against those libraries. The libraries are stored in a directory different from their source directory for two reasons:
- So all libraries can be referenced with -lmylib by just adding the library output directory to the link path with -L$(LIB_DIR)
- So the final build's directory structure matches the installation directory structure (which is essentially a sysroot)
The structure looks like this:
src/
Tuprules.tup
libA/
library.cc
Tupfile
libs/
# empty
targets/
target.cc
Tupfile
Tuprules is something like this:
DIR_LIBS = $(TUP_CWD)/libs
NEEDS_LIBA = $(TUP_CWD)/<needs_liba>
The first Tupfile builds a library like this:
include_rules
: library.cc |> g++ %f -o %o |> %B.o {objs}
: {objs} |> ar rs %o %f |> $(DIRLIBS)/libA.a
The second Tupfile tries to build and link the target like this:
include_rules
: target.cc |> g++ %f -L$(DIR_LIBS) -lA -o %o |> %B
This obviously breaks with the new explicit variants as-is, but I can't figure out how to make it work. Changing the DIR_LIBS definition to $(TUP_VARIANTDIR)/libs doesn't work, since $(TUP_VARIANTDIR) seems to be expanding based on the path it's included from (i.e. it expands to ../build/targets/ inside the targets folder). So far the only option I've found is to explicitly mess with the path by changing the target build line to something like this:
: target.cc |> g++ %f -L$(TUP_VARIANTDIR)/../libs -lA -o %o |> %B
Which isn't very scalable or robust with refactoring. Is there a better solution?
Could TUP_VARIANTDIR also be added to the official documentation? All of the above was discovered by manual experimentation and a git bisect on tup.
Thanks!