-
Notifications
You must be signed in to change notification settings - Fork 0
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
Better preinstallation and clear up installation prefix confusion #81
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…stall_prefix`, set to what's passed in `-p` or the default temporary or final installation prefix depending on the command ran, `-D` switch to replace , and remove `-t`. Phew, what a commit message
preinstallation rules
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR intends to fix a lot of the weirdness and inconsistency w.r.t. preinstallation.
Basically:
Preinstall everything, including non-cookies, and do this before anything else. This is because 1) a dependent could depend on this or 2) the runtime itself could depend on it. In fact, this needs to be extended to installation more generally, or we might get the case where we depend on a preinstalled header, but once we doRuntime is only relevant forbob install
, since we're not necessarily installing the header first, things fail to compile.run
andsh
, in which case a full installation to the temporary install prefix is done anyway. If a build step need to depend on an installed file, then it should be preinstalled (i.e. with a cookie). Possibly we could have aRes.preinstall()
function or something for this, but let's only think of that when the need arises.-B
.Dependencies are not installed; figure out if we want to do this or not.They are now, and it's going to be complicated/confusing to do this differently.build
(we could be depending on one of its headers e.g.).Prefix tests.This isn't super relevant anymore. I guess everything is for the most part covered by other tests (install, run, sh).User scenarios
This should really wind up being documentation at some point -> #82
Simply building
Currently, unless we explicitly pass the
-t
option, the prefix passed tobsys_build
is justNULL
. In that case, after the Bob bsys callssetup_install_map
, theinstall.c
prefix is set toNULL
, too. This entails thatinstall_cookie
andinstall_all
will both do nothing.When
-t
is passed, we should really run an install step (install
function, like when running) to the temporary prefix, as this takes care for everything for us. Then again, maybe it makes more sense to have a different explicit name for this to not overload thebuild
command and make things confusing. I'm thinking:preinstall
command which can take in-t
but otherwise just infers the temporary prefix, like when we're running.build-no-deps
command and replace it with a switch which prevents dependencies from being built. This can honestly be documented, there's no real reason to obscure it (the same way I guess there might be a reason to obscuredep-tree
, though even that should probably also be documented).The last thing to
Running
Currently, we start by calling
install
, which implicitly builds too. This is called withto_tmp_prefix
set obviously.Installing
Ditto, but we don't set
to_tmp_prefix
.Actually it turns out running and installing are the "easy" cases. Maybe we should just clean up
install.c
to make clear where different prefixes come from.Confusing names
I think most of the confusion here stems from nomenclature. In code (and even in this issue), the terms "prefix", "temporary installation prefix", and "preinstallation" are used inconsistently. I propose these new definitions:
install_cookie
)..bob/prefix
, but can be set through-t
. This is the prefix thatrun
andsh
use./usr/local
. This is the prefix thatinstall
uses by default.I do realize that, for the
install
command, there isn't really a need to have a separate-t
option. It acts the same whether it's installing to a temporary or final prefix. In fact, sincerun
andsh
should deterministically install to a temporary prefix by default andinstall
should deterministically install to a final prefix by default, we can get by with just a-p
option.This is quite good because it means, to build a dependency, it suffices to just run
bob -p $parent_tmp_prefix install
(instead of needing abuild-no-deps
or an (erroneously named)preinstall
command).