I'm new at this, but could you set a variable in your top-level 
Tuprules.tup with the top level directory? I'm doing something similar to 
save sub-project top paths. Something like this:

OPENSRC_DIR = $(TUP_CWD)/OurOpenSource

Then I use that in my projects' Tupfiles this way:

CFLAG += -I$(OPENSRC_DIR)/video/include

In your case, you could set your variable to this:
TOP_DIR = $(TUP_CWD)

Would this work for you?

On Friday, December 6, 2019 at 1:10:49 PM UTC-6, Szczepan Hołyszewski wrote:
>
> Is there a way to get tup to store the ABSOLUTE path of the project top 
> level directory in a variable, without actually hardcoding the path?
>
> Why I need this: I have a weird but must-live-with build tool that MUST be 
> run in the top-level project directory, no matter where the files are 
> located that a particular invocation of the tool will read or write. 
> Therefore build commands that use the problematic build tool and live in 
> Tupfiles located in subdirectories of the project root must be prefixed 
> with cd [appropriate number of ../] in order to get into the project root 
> directory before executing the tool. However if I want to use some 
> variables defined in Tuprules.tup in the tool's command line, and those 
> variables are anyhow constructed from $(TUP_CWD), then this will be broken: 
> those variables are relative to the directory of the current Tupfile, but I 
> have cd'd out of that directory before excuting the tool, and those 
> relative paths are no longer valid as relative to the tool's current 
> working directory.
>
> project/subdirectory/Tupfile
>
> include_rules
>
> : some-input-file.i |> cd .. && problematic-tool %o $(some-binary) $(some-
> dir-in-project)/whatever |> some-output.o
>
>
> project/Tuprules.tup
>
> some-binary = $(TUP_CWD)/bin/some-binary
> some-dir-in-project = $(TUP_CWD)/some/dir/in/project
>
>
> If the problematic tool could be executed from anywhere, then we could 
> just write:
>
> : some-input-file.i |> problematic-tool %o $(some-binary) $(some-dir-in-
> project)/whatever |> some-output.o
>
> When tup would execute the command, it would expand to:
>
> problematic-tool some-output.o ../bin/some-binary ../some/dir/in/project
>
> ... and this would work correctly. But the tool must be executed from the 
> project root into which we must "cd ..", and tup is unaware of that and 
> doesn't adjust ".." to ".".
>
> How can I overcome this problem without too much refactoring? Ability to 
> store the absolute path to the project root in a variable would be THE 
> silver bullet here. It would completely solve the problem.
>
>

-- 
-- 
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/b3a6ea24-9727-469d-ada6-2d587e3c2af2%40googlegroups.com.

Reply via email to