Observation
The first real consumer of the artifacts edge (#711, mcpp 2026.9.27.1) fails planning. GalTranslPP's GUI ships its updater beside itself; with
# GPPGUI/mcpp.toml
[dependencies]
"gpp.updater" = { path = "../Updater", artifacts = ["Updater"] }
mcpp emit build-database (and mcpp build) on Windows reports
GPPGUI: runtime deploy collision: '<cache>\target\.build-mcpp\out\qt\translations\qt_zh_CN.qm' and
'<cache>\target\.build-mcpp\deps\[email protected]\out\qt\translations\qt_zh_CN.qm' both target 'bin\translations\qt_zh_CN.qm'
(Sunrisepeak/GalTranslPP run 36312954298, mcpp 2026.9.27.1, mcpp:plugins 0.16.0.)
Both programs are Qt programs whose build programs ask rules-qt for Qt's own Chinese strings (i18n.qt_languages = {"zh_CN"}). Each writes qt_zh_CN.qm into its own out directory and deploys it to translations/. The artifact program runs from the consumer's directory, so its deploy set joins the consumer's, and add_deploy (src/build/plan.cppm) refuses two different source paths for one destination.
The two files are byte-for-byte the same: for these modules (Core, Gui, Network, Widgets on one side, Core, Gui, Widgets on the other) rules-qt combines the one catalog qtbase_zh_CN.qm of the same SDK with the same lconvert command; only the output path differs. At planning time neither file exists, so the check cannot compare contents. The Qt runtime libraries and plugins of the two programs do not collide, because they are deployed from the same payload paths and deduplicated.
Question for the design
What should a program shipped through artifacts do with a runtime file its consumer also deploys under the same name? Some options:
- The consumer's own deploy set takes precedence over what an
artifacts edge brings, with a note naming the file that was not placed; a program placed in the consumer's directory already shares that directory's files.
- Two deploys whose sources are outputs of actions with the same command and the same inputs (differing only in the output path) are the same file, and one is placed.
- The edge accepts a list of deploy entries to leave out.
Until one of these is decided, GalTranslPP's validation keeps the updater on a tools edge.
Observation
The first real consumer of the
artifactsedge (#711, mcpp 2026.9.27.1) fails planning. GalTranslPP's GUI ships its updater beside itself; withmcpp emit build-database(andmcpp build) on Windows reports(Sunrisepeak/GalTranslPP run 36312954298, mcpp 2026.9.27.1, mcpp:plugins 0.16.0.)
Both programs are Qt programs whose build programs ask
rules-qtfor Qt's own Chinese strings (i18n.qt_languages = {"zh_CN"}). Each writesqt_zh_CN.qminto its own out directory and deploys it totranslations/. The artifact program runs from the consumer's directory, so its deploy set joins the consumer's, andadd_deploy(src/build/plan.cppm) refuses two different source paths for one destination.The two files are byte-for-byte the same: for these modules (Core, Gui, Network, Widgets on one side, Core, Gui, Widgets on the other)
rules-qtcombines the one catalogqtbase_zh_CN.qmof the same SDK with the samelconvertcommand; only the output path differs. At planning time neither file exists, so the check cannot compare contents. The Qt runtime libraries and plugins of the two programs do not collide, because they are deployed from the same payload paths and deduplicated.Question for the design
What should a program shipped through
artifactsdo with a runtime file its consumer also deploys under the same name? Some options:artifactsedge brings, with a note naming the file that was not placed; a program placed in the consumer's directory already shares that directory's files.Until one of these is decided, GalTranslPP's validation keeps the updater on a
toolsedge.