-
Notifications
You must be signed in to change notification settings - Fork 109
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
relocatable installation #304
Comments
Nice idea. I would suggest to have a So this change would in principle only touch makefiles and the configure script. Some new specific make rules may be needed though, as the |
This comment has been minimized.
This comment has been minimized.
I am not an expert at all in this field, but it seems to me that if you
come up with a solution taht is "relocatable" there would be no need to
make it (another) user configurable option at build as if it is really
relocatable it will also work without relocating it, or am i missing
something trivial?
Roberto
…On Mon, Feb 15, 2021 at 1:06 PM Nick Papior ***@***.***> wrote:
Isn't DESTDIR support the way to go? That seems standardizable in
automake ... ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#304 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABEJ6O2QUP53IMHDRH2BET3S7EE57ANCNFSM4JTDGV4Q>
.
|
@RobyB I suggested to have a configure option as from my understanding relocatable installation goes against reproducible installation where people want to fully qualify every paths. @zerothi |
Currently modules hard-codes many paths into its source and implementation before it's installed. If that installation is moved, it's broken. This is problematic for various packaging systems, especially those that make aggressive use of caching (the ones I care about are: pypi, homebrew).
Let's make the modules installation relocatable. This means we can move the installation and it continues to work. What's more, a package manager can make a tarball of an "installed" environment-modules, then use (and reuse) that tarball whenever (and whereever) environment-modules is installed.
I'll be hacking away at this task in a personal branch, but if you'd give me any pointers as to how to make this most palatable to merging upstream (to your branch), it would be most welcome.
In general, my strategy is to use the current code to embed absolute paths, but convert them to prefix-relative paths before they're used. In this way, I can
./configure --prefix=$olddir; make; make install; mv $olddir $newdir
, and although $olddir/bin is still hard-coded various places, the system will work because there's an intermediate conversion that usesprefix=$olddir
andbindir=$olddir/bin
to generate a relative path$MYPREFIX/bin
The text was updated successfully, but these errors were encountered: