Skip to content

Make YGGDRASIL_DIR an "official" variable set in recipes #12555

@fingolfin

Description

@fingolfin

A bunch of recipes now do something like this:

const YGGDRASIL_DIR = "../../.."
include(joinpath(YGGDRASIL_DIR, "fancy_toys.jl"))

I think this is an excellent idea, making it a tad easier to move recipes into subdirectories, and generally making it clearer what the intent is. Increased consistency also helps people trying to get into the Yggdrasil ecosystem, which is getting more complex as time goes on. This was also motivation for making PR #12554 which changes even more to use follow this pattern.

Now IMHO it would be even nicer if the recipes did not have to set YGGDRASIL_DIR.

I wonder: can't we somehow come up with a way to set this variable before the script is executed?

Of course any solution needs to take into account that one should still be able to build recipes locally, and not just inside the BuildKite runners driving Yggdrasil. In the latter, it would of course be easy to set YGGDRASIL_DIR, but in the former a user could run julia build_tarballs.jl anywhere; and in fact, users might use BB entirely outside of Yggdrasil (e.g. a company who uses BB to make binaries of their own proprietary tech).

Here is one idea: we add a helper locate_yggdrasil(dir) to BB. Recipes call it like this:

const YGGDRASIL_DIR = BinaryBuilder.locate_yggdrasil(@__DIR__)

That function then could recursively look at the given directory and its parent directory, until it finds one it considers an "Yggdrasil root". The decision for that could be made based on the presence of a magic file, say .yggdrasil_root; or on some existing file such as fancy_toys.jl. The former has the advantage that any "alternate yggdrasil" could also benefit from it... Though then perhaps leaving "yggdrasil" out of the filename would be even better (and then locate_yggdrasil could be renamed, too -- suggestions welcome)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions