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

Some variables aren't properly set #4704

Closed
dilyn-corner opened this issue Mar 29, 2024 · 5 comments
Closed

Some variables aren't properly set #4704

dilyn-corner opened this issue Mar 29, 2024 · 5 comments
Assignees
Labels
bug Actual bad behavior that don't fall into maintenance or documentation

Comments

@dilyn-corner
Copy link

dilyn-corner commented Mar 29, 2024

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.

@dilyn-corner dilyn-corner added the bug Actual bad behavior that don't fall into maintenance or documentation label Mar 29, 2024
Copy link

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
Copy link
Contributor

lengau commented Apr 3, 2024

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
Copy link
Contributor

tigarmo commented Apr 5, 2024

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
Copy link
Collaborator

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
Copy link
Collaborator

mr-cal commented Apr 25, 2024

Fixed via #4757.

CRAFT_PROJECT_NAME and CRAFT_PROJECT_VERSION are still not evaluated. Tracking with canonical/craft-application#320

@mr-cal mr-cal closed this as completed Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Actual bad behavior that don't fall into maintenance or documentation
Projects
None yet
Development

No branches or pull requests

5 participants