Feature request: path to root directory and root relative

[p2rkw]

Hi, I need one variable with path to root directory and one with relative path from root directory to RUNNING directory (with currently parsed Tupfile). I need this to force GCC to emit proper file locations to source files for GDB. GDB needs relative path from binary to to source file, currently with one Tupfile per directory this path get lost.

Is it possible to get directory where tup was initialized? Is it possible to get directory from tup's root to current Tupfile?

If not, I'd like to suggest adding them :)

If think I can add these variables (TUP_ROOT and TUP_RWD maybe?), but I need your green light.

So, Is it OK to add them? Are you going to add them?

[KamilSzczygiel]

Put this in your top-level Tuprules.tup:

TOP = $(TUP_CWD)

If you use lua, use this in Tuprules.lua:

TOP = tup.getcwd()

Now wherever you use this variable it will be expanded to relative path between place of use and tup-level folder of project. For example like that:

!cxx = |> $(CXX) $(CXXFLAGS) $(CXXFLAGS_%f) -c %f -o %o |> %B.o $(TOP)/<objects>

CXXFLAGS += -I $(TOP)

Additionally - aren't you trying to do something that is accomplished by ^c flag? I can debug programs compiled with tup in GDB without any issues...

[p2rkw]

As I remember I tried to fix it that way, but TUP_CWD were always expanded to '.'. My sources are placed in 'src' directory with multiple subdirectories. I have separate Tupfile for each of them. I will try this one more time later. Which version of tup you are using?

[KamilSzczygiel]

This (the variable $(TOP) or whatever you call it) HAS TO be put in top-level Tuprules.tup or Tuprules.lua, not in Tupfile. $(TUP_CWD) is expanded to . is 99% places of use, that's why you assign value of $(TUP_CWD) for top-level folder to a variable. It works for me since I started using tup over 2 years ago and still works fine. Both on Windows and Linux.

[p2rkw]

So, trick with TOP variable works, but I still need path relative from root directory to current directory (lets call it TUP_RWD).

Let me explain why: I have followig tree structure:

── build-debug
│   ├── a.out
│   ├── configs
│   ├── list.txt
│   ├── main.o
│   ├── module1
│   │   └── module1.o
│   ├── module2
│   │   ├── module2.o
│   │   ├── test2.txt
│   │   └── test.txt
│   └── tup.config -> ../configs/debug.conf
├── configs
│   └── debug.conf
├── main.cpp
├── module1
│   ├── module1.cpp
│   └── Tupfile
├── module2
│   ├── module2.cpp
│   └── Tupfile
├── Tupfile
└── Tuprules.tup

As you can see I'm using one variant named debug. GDB needs path to original source files, information where to look for them is encoded in final binary, so I checked it: objdump -W build-debug/a.out | grep 'module2' and result:

    <11>   DW_AT_name        : (indirect string, offset: 0x120): module2.cpp
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0xb1): /home/pawel/dev/tupTest0/.tup/mnt/@tupjob-73/home/pawel/dev/tupTest0/build-debug/module2
    <68a>   DW_AT_name        : (indirect string, offset: 0x102): module2
    <690>   DW_AT_linkage_name: (indirect string, offset: 0x252): _Z7module2v
  1 0   0   0   module2.cpp

As you can seed 'DW_AT_comp_dir' points to virtual directory, and as a result GDB can't find source file. I think when I run gcc with option '-fdebug-prefix-map=.=$(TUP_RWD)' it will point to correct directory.

[KamilSzczygiel]

As I suspected (; Add ^c flag to your compilation commands (see tup's manual) and do whatever is necessary to enable chroot build with tup and your problem will be solved.

[KamilSzczygiel]

Anyway - it would be an interesting option to actually make your original proposal work, because compilation in chroot on Linux is ~2x slower than normal compilation ); It would be a nice workaround for GCC (;

[p2rkw]

Thanks for reply, I will try ^c flag later.

But I already implemented it here: https://github.com/gittup/tup/pull/226 so you can checkout my branch, test it and share your thougts :)

[gittup]

I don't think it makes sense to add variables like TUP_ROOT, since the root of the project may vary (eg: if a user runs 'tup init' at one level higher, or your project is used as a submodule of another project, etc). This is why making relative roots in Tuprules.tup with $(TUP_CWD) was designed the way it is.

I'd like to fix the gdb-with-variants issue (as well as the variants-on-windows issue) by using explicit variants rather than the FUSE overlay instead.

[Jose123456]

Big problem with this is that ^c... does not work on Mac

tup error: This process requires namespacing, but this kernel does not support namespacing and tup is not privileged. You'll need to upgrade your kernel, or compile tup with CONFIG_TUP_SUDO_SUID=y in order to support the ^c flag.
 *** tup messages ***
 *** Command ID=379 failed with return value 1

And the homebrew tup package does not have CONFIG_TUP_SUDO_SUID as an option

Update:

I looked into adding that option to the brew recipe, and it is unlikely that a patch implementing that would ever by accepted by homebrew because it would require root privileges during the installation of tup. The only way to produce debug binaries in Mac OS X is to manually set the tup binary suid root. You also get massively degraded performance for your trouble.

It would be really nice if tup could expose the .tup/mnt/@tupjob-nn paths in an @-variable so that workarounds using -fdebug-prefix-map like this one could be possible.