canonical / snapcraft

Package, distribute, and update any app for Linux and IoT.
https://snapcraft.io
GNU General Public License v3.0
1.18k stars 440 forks source link

Some variables aren't properly set #4704

Closed dilyn-corner closed 4 months ago

dilyn-corner commented 5 months ago

Bug Description

When building a core24 snap for a different architecture, the BUILD_FOR variables are set to the host architecture instead of the target.

This might be similar to #4702

To Reproduce

Install snapcraft from latest/edge (tested with revision 11178) snapcraft, snapcraft --build-for riscv64, and snapcraft --build-for=riscv64 all fail to set the correct architecture. Curiously, snapcraft --build-for amd64 returns no errors but also doesn't do anything (no-op with no message?) but that may be unrelated.

Environment

Snapcraft on a 23.10 host building with --use-lxd.

snapcraft.yaml

name: my-snap-name # you probably want to 'snapcraft register <name>'
base: core24 # the base snap is the execution environment for this snap
build-base: devel
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line elevator pitch for your amazing snap # 79 char long summary
description: |
  This is my-snap's description. You have a paragraph or two to tell the
  most important story about your snap. Keep it under 100 words though,
  we live in tweetspace and your description wants to look good in the snap
  store.

grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots

platforms:
  riscv64:
    build-on: [amd64, riscv64]
    build-for: [riscv64]

parts:
  my-part:
    # See 'snapcraft plugins'
    plugin: nil
    override-build: |
      echo BUILD_FOR is "${CRAFT_ARCH_BUILD_FOR}"
      echo BUILD_ON  is "${CRAFT_ARCH_BUILD_ON}"
      echo TRIPLET_BUILD_FOR is "${CRAFT_ARCH_TRIPLET_BUILD_FOR}"
      echo TRIPLET_BUILD_ON is "${CRAFT_ARCH_TRIPLET_BUILD_ON}"
      echo PROJECT_NAME is "${CRAFT_PROJECT_NAME}"
      echo PROJECT_VERSION is "${CRAFT_PROJECT_VERSION}"

Relevant log output

Starting snapcraft, version 8.0.5.post149+git2fd36174
Logging execution to '/home/dilyn/.local/state/snapcraft/log/snapcraft-20240329-130845.515502.log'
Starting snapcraft, version 8.0.5.post149+git2fd36174
Logging execution to '/home/dilyn/.local/state/snapcraft/log/snapcraft-20240329-130845.515502.log'
Launching managed ubuntu devel instance...
Starting instance
Starting snapcraft, version 8.0.5.post149+git2fd36174
Logging execution to '/tmp/snapcraft.log'
Starting snapcraft, version 8.0.5.post149+git2fd36174
Logging execution to '/tmp/snapcraft.log'
Initialising lifecycle
Installing build-packages
Installing build-snaps
Skipping pull for my-part (already ran)
Building my-part
:: + echo BUILD_FOR is amd64
:: BUILD_FOR is amd64
:: + echo BUILD_ON is amd64
:: BUILD_ON is amd64
:: + echo TRIPLET_BUILD_FOR is x86_64-linux-gnu
:: TRIPLET_BUILD_FOR is x86_64-linux-gnu
:: + echo TRIPLET_BUILD_on is x86_64-linux-gnu
:: TRIPLET_BUILD_ON is x86_64-linux-gnu
:: + echo PROJECT_NAME is my-snap-name
:: PROJECT_NAME is my-snap-name
:: + echo PROJECT_VERSION is 0.1
:: PROJECT_VERSION is 0.1
Staging my-part
Priming my-part
Packing...
Reading snap metadata...
Running linters...
Running linter: classic
Running linter: library
Creating snap package...
Packed my-snap-name_0.1_riscv64.snap

Additional context

Also of note: SNAPCRAFT_PROJECT_{NAME,VERSION} are invalid variables (though their CRAFT_ counterparts are valid), which means the documentation is incorrect. SNAPCRAFT_PROJECT_GRADE and CRAFT_PROJECT_GRADE are never replaced and both raise an unbound variable error, but I think these things are more related to #4702 than this bug.

syncronize-issues-to-jira[bot] commented 5 months ago

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-2657.

This message was autogenerated

lengau commented 5 months ago

I think this has the same root cause as #4702, so I would guess that the full fix for one would fix both. However I'm not going to close this as a duplicate and update the other bug for it because I'm only about 80% sure 😄

tigarmo commented 5 months ago

If I were a gambling man I would bet that the problem is that we aren't doing the equivalent of this in core24 projects

sergiusens commented 5 months ago

extract the method Tiago mentions and call it also from Application._set_global_environment (https://github.com/canonical/craft-application/blob/1508796257c305a0b55e1af92056f82d2806f994/craft_application/application.py#L649 , requires calling parent)

mr-cal commented 4 months ago

Fixed via #4757.

CRAFT_PROJECT_NAME and CRAFT_PROJECT_VERSION are still not evaluated. Tracking with https://github.com/canonical/craft-application/issues/320