Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    • Menu
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • LilyPond LilyPond
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,009
    • Issues 1,009
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 17
    • Merge requests 17
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LilyPond
  • LilyPondLilyPond
  • Merge requests
  • !635

Prepare for compiled bytecode

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Jonas Hahnfeld requested to merge hahnjo/lilypond:guile2-compile into master Feb 05, 2021
  • Overview 4
  • Commits 2
  • Pipelines 2
  • Changes 5

Guile has two code paths for loading bytecode:

  1. When loading a module by name (via (use-modules) or by passing a relative argument to (primitive-load-path), ie no file extension), Guile will append ".go" and search its %load-compiled-path. (That path can be controlled via GUILE_LOAD_COMPILED_PATH.)

If no such compiled file is found or (primitive-load-path) was passed a filename directly, %search-load-path tries to append any extension of %load-extensions (usually "" and ".scm") and searches a file of that name from %load-path (can be controlled via GUILE_LOAD_PATH). If successful Guile uses the first file it finds.

  1. Before loading a source file (no matter how it was found), Guile checks its compile cache for an entry of the absolute path of the file appended with ".go". By default, the cache is located at $XDG_CACHE_HOME/guile/ccache/ plus some version specific directory. For LilyPond, setup_guile_v2_env sets XDG_CACHE_HOME to the data directory.

For local development, the latter fallback path works and is convenient for experiments. However, it's not suitable for distribution because it contains absolute paths and is not relocatable. Hence, change the logic to load files by relative names so that one day it will be possible to inject compiled bytecode.

(Side note: It's not actually relevant if the found file really declares a module with that name; there may be no (define-module) at all or with a different name. (primitive-load-path) doesn't care, but (use-modules) will print an error that it couldn't find code for the module after it loaded the file, for obvious reasons.)


scm: Replace with-location by explicit calls

To make ly-syntax-constructors.scm compilable into bytecode, it would be required to have direct access to the %location fluid. That defeats the purpose that there are no public setters, so solve the problem by calls to (ly:set-origin!) with an explicit location. I've verified that a \addlyrics command still results in the same value of 'origin for the created ContextSpeccedMusic and LyricCombineMusic.

This effectively reverts the following two commits from Issue #4474 (closed):
873f9fd2 Issue 4474/5: Provide with-location macro
8499cabe Issue 4474/6: Combine lyric-combine and lyric-combine-music

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: guile2-compile