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

Better preinstallation and clear up installation prefix confusion #81

Merged
merged 23 commits into from
Dec 22, 2024

Conversation

obiwac
Copy link
Member

@obiwac obiwac commented Dec 21, 2024

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 do bob install, since we're not necessarily installing the header first, things fail to compile. Runtime is only relevant for run and sh, 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 a Res.preinstall() function or something for this, but let's only think of that when the need arises.
  • Add include path to compiler flags. -> Done with -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.
  • Always preinstall for a dependency, even when just doing a 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).
  • Check that installed files are being chown'd correctly, even for dependencies (add this to chown test).
  • Use this opportunity to use human names for dependencies in logs when building them.

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 to bsys_build is just NULL. In that case, after the Bob bsys calls setup_install_map, the install.c prefix is set to NULL, too. This entails that install_cookie and install_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 the build command and make things confusing. I'm thinking:

  • New preinstall command which can take in -t but otherwise just infers the temporary prefix, like when we're running.
  • Remove the 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 obscure dep-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 with to_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:

  • Preinstallation: Purely the act of installing stuff before we've finished building. This is always the case when installing cookies (see install_cookie).
  • Installation prefix: The generic term for a prefix, temporary or final, to which we install.
  • Temporary prefix: By default .bob/prefix, but can be set through -t. This is the prefix that run and sh use.
  • Final prefix: The default depends on the system, but on FreeBSD this would be /usr/local. This is the prefix that install 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, since run and sh should deterministically install to a temporary prefix by default and install 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 a build-no-deps or an (erroneously named) preinstall command).

@obiwac obiwac added the enhancement New feature or request label Dec 21, 2024
@obiwac obiwac changed the title Better preinstallation Better preinstallation and clear up installation prefix confusion Dec 21, 2024
…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
@obiwac obiwac merged commit a39368e into main Dec 22, 2024
8 checks passed
@obiwac obiwac deleted the feature/better-preinstallation branch December 22, 2024 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant