What is the proper solution for working outside $HOME?

Hardware Adaptation
#1

Insert obligatory pandemic joke here

How can i use sfossdk (mer-sdk-chroot) with tooling and code that is outside my $HOME? Surely there is a go-to solution, and i’m missing something.

Tools both outside and inside and inside the chroot env lean on the same $PLATFORM_SDK_ROOT variable in the same ~/.bashrc, but the only thing that is mounted under the same path is /home/$USER. So e.g. /media/$USER/my_other_disk will in fact not even be that other disk inside the chroot. I think i could maybe work around it for setting up the tooling if i pay attention… (not sure it will be usable) But when it comes to accessing the source code that needs to be fetched using the “repo” tool in the host environment, i’m honestly lost.

I can’t be the first person who cannot casually put 100GB on the system drive :slight_smile:

#2

With the latest chroot (based on Sailfish OS 4.0.1) you should be able to fix it by exporting SAILFISH_SDK_SRC1_MOUNT_POINT so that it points to the top of your workspace that is outside home. You can export it from ~/mersdk.profile. Paths outside the chroot can be accessed via /parentroot, so prepend that to your host path.

Example: If your other disk is mounted at /media/$USER/my_other_disk, you can set SAILFISH_SDK_SRC1_MOUNT_POINT=/parentroot/media/$USER/my_other_disk/optional/sub/path in ~/mersdk.profile.

(With older releases, bind mounting the path somewhere under your home should work equally well.)

1 Like
#3

Okay, so i guess i didn’t understand. Putting SAILFISH_SDK_SRC1_MOUNT_POINT=/media/attah/bulk/src in .mersdk.profile seems to have done nothing for me, or i’m just not far along enough in the process. Where would this come in and, what would it effect?

I.e. would it help me with the other variables/paths?

The problem i’m having is PLATFORM_SDK_ROOT and ANDROID_ROOT needing to be different paths on host vs sfossdk/ubu-chroot. (with and without /parentroot)

So i tried overriding those variables in .mersdk.profile, but it only works in sfossdk. Ubu-chroot seems to re-read my host .bashrc and .hadk.env and get the paths set to the same place as on host again.

#4

In my original reply I mentioned the need to prefix the path with /parentroot, but later in the example I failed to do so - edited. Try SAILFISH_SDK_SRC1_MOUNT_POINT=/parentroot/media/attah/bulk/src.

This environment variable affects scratchbox2’s behavior - files under a file system tree designated this way will be treated as source code and build artifacts. Files inside user’s home are treated this way unconditionally, so this only needs to be done to make scratchbox2 working for sources located outside user’s home.

I don’t follow what you mean with the other paths. Let’s see if this still is an issue after fixing the prefix.

#5

Ah, okay, my problem is not (yet) related to scratchbox2.

My problem is $PLATFORM_SDK_ROOT and $ANDROID_ROOT (“the other variables/paths”), where they are expected to resolve both inside and outside the chroot(s), but the place(s) to define them is shared with the host.

(Defining them with /parentroot makes them not resolve on host, defining them from /media makes me mkdir -p a directory in the chroot that isn’t actually shared with the host)

Sure, i can override them (manually or with some dirty logic), but it’s like setting a trap for myself, so i wonder if there is a good way to keep them in sync and resolving.

#6

Creating ~/.mersdkrc with content like this might work for you:

mount_sdk()
{
    ln -sfn {/parentroot,"$sdkroot"}/media/attah
}

Should there be an issue using a symlink for your particular purpose, you can bind mount instead:

mount_sdk()
{
    mkdir -p "$sdkroot"/media/attah || return
    mount --bind {,"$sdkroot"}/media/attah
}

(The symlink way is more flexible: the media does not need to be mounted at the time you enter the SDK and you do not need to leave the SDK in order to unmount the media.)

#7

Neat! That solves it for PLATFORM_SDK, but i still have the issue in HABUILD_SDK. However, doing that same symlink in the Ubuntu chroot doesn’t work, as it complains about “too many symlinks”.

Trying the mount route as a workaround, i must have gotten something mixed up, since it didn’t work, and going back i had an extra “attah”. I’ll faff about with that again when i have some more time on my hands.

Thanks for helping, sorry for being hard to help (:

#8

This is likely caused by a circular reference.