Workspace packages cannot have different enable-gas settings (executables vs contracts)

[feltroidprime]

Summary

In a workspace containing both executable targets and starknet-contract targets, it's impossible to compile executables because the [cairo] enable-gas setting cannot be configured per-package.

Current Behavior

When a workspace contains:

1. A package with executable targets (requires enable-gas = false)
2. A package with starknet-contract targets (requires enable-gas = true)

Running scarb execute on the executable fails with:

error: executable target cannot be compiled with enabled gas calculation

The warning message confirms the limitation:

warn: in context of a workspace, only the `cairo` set in the workspace manifest is applied,
but the `falcon` package also defines `cairo` in the manifest

Reproduction

Workspace Scarb.toml:

[workspace]
members = ["packages/*"]

Package A (packages/falcon/Scarb.toml) with executable:

[package]
name = "falcon"
version = "0.1.0"
edition = "2024_07"

[cairo]
enable-gas = false

[[target.executable]]
name = "bench_ntt_bounded_int"
function = "falcon::programs::bench_ntt_bounded_int::main"
sierra = true

Package B (packages/test-contract/Scarb.toml) with contract:

[package]
name = "test_contract"
version = "0.1.0"
edition = "2024_07"

[[target.starknet-contract]]
sierra = true
casm = true

[dependencies]
falcon = { path = "../falcon" }

Running:

scarb execute --executable-name bench_ntt_bounded_int --package falcon

Fails because the package-level enable-gas = false is ignored.

Expected Behavior

One of:

1. Per-package [cairo] settings should be respected in workspaces
2. Or enable-gas could be configurable per-target type (executables vs contracts)
3. Or at minimum, --package flag should use that package's [cairo] settings

Environment

• scarb version: 2.15.1
• OS: Linux

Workaround

Currently the only workaround is to move the executable package outside the workspace, which breaks the dependency relationship.

[Arcticae]

Can't profiles be used in your case to circumvent this?

[workspace]
members = [
    "my_executable",
    "my_contract",
]

# Per-package [cairo] is ignored in workspaces, so we use named profiles instead.
# Build executables with:  scarb --profile executable_prof build --package my_executable
# Build contracts with:    scarb --profile contract_prof build --package my_contract


[profile.executable_prof.cairo]
enable-gas = false

[profile.contract_prof.cairo]
enable-gas = true

[piotmag769]

Or enable-gas could be configurable per-target type (executables vs contracts)

This seems like a useful feature cc @maciektr

Per-package [cairo] settings should be respected in workspaces

Just to explain - this is a result of a limitation of Cairo compiler - some settings there are global. enable-gas being "global setting" for the compiler makes sense if you think about it. If you have a case of a function A from crate that has enable-gas = false then it cannot call e.g. a function B from crate with enable-gas = true since you don't have GasBuiltin pointer implicit argument. It would be quite unintuitive.

[wawel37]

Reminder for a person that will be assigned for that. Please provide a design doc for that in the slack channel