Specialize parts based on architecture

Is there any way to specialize the variables of a part based on the architecture?

The specific use-case here is to create a snap from prebuilt upstream binaries, where a different source file (and hence different source-checksum) would be required for each architecture.

1 Like
      on amd64: url-to-amd64-source
      on i386: url-to-i386-source
      on amd64: checksum-for-amd64
      on i386: checksum-for-i386

Does that not work?


D’oh! That’s indeed what I was thinking of, but had forgotten the syntax, and didn’t find by searching (I see now that it’s in the Advanced grammar docs section). Thanks very much!

1 Like

To be fair, unless you know it’s called “Advanced grammar” it’s a touch hard to find. I think we’d be better off making that page a little different with some examples and words like “architecture specific”.
What do you think @degville?

1 Like

That said, it doesn’t seem to work for source-checksum:

    - on amd64: "sha3_512/a407dc067b82c5f6ac325dd1be4d5718c05149fffe3d2de82f02b536fa388e669499d45ce8e0f65bf049b3e33ba2a103fdee77fbd5e427e4da9d0bbee6ec8b33"

… results in the following error:

Issues while validating snapcraft.yaml: The 'parts/ldc/source-checksum' property does not match the required schema: [OrderedDict([('on amd64', 'sha3_512/a407dc067b82c5f6ac325dd1be4d5718c05149fffe3d2de82f02b536fa388e669499d45ce8e0f65bf049b3e33ba2a103fdee77fbd5e427e4da9d0bbee6ec8b33')])] is not of type 'string'

Agreed. I think it would be a great help if this syntax was referenced from the https://snapcraft.io/docs/architectures page, which is where I went looking for it (and got confused when I couldn’t find it).

Booo! Sounds like we need to cast a spell of invocation :mage: @cjp256 - can you help here?

1 Like

Yea, it’s quite an “Ouch!” oversight, isn’t it? :laughing: Looking forward to seeing the magic being worked.

TBH I’m not sure I even understand why on ... specializations are restricted to only a subset of vars – I presume just in order to help the developers avoid having to deal with debugging all the potential combinatorical variations that users could come up with?

I think this is a really good idea - an overhaul of our Advanced Grammar doc(s) has been on my target list for a long time. It’s difficult to understand, difficult to find and missing some important pieces, but I’ll try to prioritise it.


I believe @sergiusens is interested in expanding the advanced grammar to work across the entire (most?) of the YAML.

At minimum, there is clearly a strong case for it to work with source-checksum as well @joseph.wakeling.


That’s great to hear. Thanks everyone for being so responsive – it helped me move forward today with a number of things that had been blocked for a while.