Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

helper to convert from host to chroot path #2730

Open
nekopsykose opened this issue Aug 18, 2024 · 10 comments
Open

helper to convert from host to chroot path #2730

nekopsykose opened this issue Aug 18, 2024 · 10 comments

Comments

@nekopsykose
Copy link
Member

mostly would instantly be used for #2683

example impl in #2576 host_path_to_chroot

@nekopsykose
Copy link
Member Author

locally i also used something like this for something like

self.do("llvm-profdata", "merge", (self.cwd / "someshit").glob("*.profdata"), "-output", "merged.profdata")

where by default this fails, because the self.cwd view is host, but .do executes in chroot context. so sometimes it's needed to convert these to be able to pass cwd-based globs into something to a .do (since .glob is afaict only usable from a pathlib.Path, but the only way to get one of those is self.cwd or similar, since we can't import Path and do Path(".").glob() for relative, and the existing chroot_ vars don't work because the glob is done from host context)

unrelatedly that means another useful thing to add is something that is just Path(".") instead of /full/path for cwd, but i have no idea what that would be called

@q66
Copy link
Member

q66 commented Aug 21, 2024

the issue is mainly that the host view may differ based on where the chroot path is, as the chroot consists of multiple mounts which may point to wildly different paths outside, so implementing this generically is bound to be inefficient, as it would require multiple path checks to see what to map to

normally when using stuff right now you you do something like... self.chroot_builddir / path.relative_to(self.builddir) or equivalent for different mounts (basically using the "closest" defined path pair to what you are dealing with)

this is not particularly efficient either and is somewhat clunky but so far i haven't been able to find anything better

@nekopsykose
Copy link
Member Author

guess so

the second case of having a pathlib.Path(".") exposed would solve my own immediate issue and should be very easy :)

@q66
Copy link
Member

q66 commented Aug 22, 2024

how would it be easy? having an actual relative path object is never useful since we never change the physical cwd, so it would not match anything ever

@nekopsykose
Copy link
Member Author

does cbuild rely on its own cwd being in cports presently for any internals or nah

if not you could make cwd . and make it chdir somewhere more useful for every step

@nekopsykose
Copy link
Member Author

the issue is mainly that the host view may differ based on where the chroot path is, as the chroot consists of multiple mounts

i only see this ever being useful relative to builddir and not any of the others so that seems fine

@nekopsykose
Copy link
Member Author

if not you could make cwd . and make it chdir somewhere more useful for every step

(this is a terrible idea)

@nekopsykose
Copy link
Member Author

i think the relative_to is fine actually, and you don't need the first part either; just path.relative_to(self.builddir) alone gives you a relative path that should work fine when passed to .do, but self.builddir is not something that exists since we removed it :P

@nekopsykose
Copy link
Member Author

seems self.srcdir is the exact same path though so that works

@q66
Copy link
Member

q66 commented Aug 22, 2024

the issue is mainly that the host view may differ based on where the chroot path is, as the chroot consists of multiple mounts

i only see this ever being useful relative to builddir and not any of the others so that seems fine

is used with destdir too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants