Hi Christopher,
On Wed, Sep 15, 2021 at 2:58 AM Christopher Corsi <[email protected]> wrote:
> DIR_LIBS = $(TUP_CWD)/libs
> NEEDS_LIBA = $(TUP_CWD)/<needs_liba>
>
Unrelated to your issue, but it looks like you might be creating a separate
group for each library (presumably since you have a needs_liba group, you
would also have needs_libb, needs_libc groups?). You should just be able to
use a single group, like $(TUP_CWD)/<libs> that corresponds to the
"generate libraries" stage, so all libraries can also list this <libs>
group as an output, and all binaries can list the same group as an input.
>
> 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:
>
Thanks for reporting this, this is definitely an issue. The problem is that
tup is expecting all paths to point to the srcdir, and then if a variant is
enabled, it will convert the output paths to point to the variant dir. So
when you have an output path that already points inside the variantdir, tup
doesn't realize it and makes it try to point inside the variantdir again
and it ends up creating the library in build/build/libs/ instead of
build/libs/. I'm working on a fix but it's not a quick one unfortunately.
>
> : 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?
>
One way it can work now until I get the above issue fixed is to have two
separate variables, so that the outputs use $(TUP_CWD) based paths and
things like -L use $(TUP_VARIANTDIR) based paths. Something like this patch
applied to your example:
diff --git a/Tuprules.tup b/Tuprules.tup
index 04f2ccf..3bad3d7 100644
--- a/Tuprules.tup
+++ b/Tuprules.tup
@@ -1,2 +1,3 @@
DIR_LIBS = $(TUP_CWD)/libs
+VARIANT_LIBS = $(TUP_VARIANTDIR)/libs
NEEDS_LIBA = $(TUP_CWD)/<needs_liba>
diff --git a/targets/Tupfile b/targets/Tupfile
index 8db422e..4ec1623 100644
--- a/targets/Tupfile
+++ b/targets/Tupfile
@@ -1,2 +1,2 @@
include_rules
-: target.c | $(DIR_LIBS)/<libs> |> g++ %f -L$(DIR_LIBS) -lA -o %o |> %B
+: target.c | $(DIR_LIBS)/<libs> |> g++ %f -L$(VARIANT_LIBS) -lA -o %o |> %B
>
> 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.
>
>
Ugh, sorry about that. I really appreciate you taking the time to work
through this and reporting your findings.
-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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tup-users/CA%2B6x0LXGtz%2B90mJSrfCTtdN%3DCR4VE5fT3S8m%2B%2BiBtVCJKUbGWg%40mail.gmail.com.
