natmod: Do not share build directory across architectures.#19339
Open
agatti wants to merge 3 commits into
Open
natmod: Do not share build directory across architectures.#19339agatti wants to merge 3 commits into
agatti wants to merge 3 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #19339 +/- ##
==========================================
- Coverage 98.51% 98.50% -0.01%
==========================================
Files 176 176
Lines 22903 22903
==========================================
- Hits 22562 22561 -1
- Misses 341 342 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Code size report: |
Octoprobe PR report
FailuresGroup: run-tests.py --test-dirs=extmod_hardware
Group: run-tests.py --test-dirs=extmod_hardware --emit-native
Group: run-tests.py --via-mpy --emit native
|
dpgeorge
reviewed
Jun 16, 2026
dpgeorge
reviewed
Jun 17, 2026
This commit modifies the native modules build system to use different
directories for different architectures.
Previously, the natmod build system would unconditionally put all build
data into a single directory (usually "$(PWD)/build" unless overridden),
and the static library runtime cache into another directory
("$(PWD)/.mpy_ld_cache"). That works if building is always done for a
single architecture or if a full clean is performed before switching
architectures, which sometimes is not wanted (collecting the runtime
cache may take quite some time depending on the module complexity, for
example).
With these changes, both the build directory and the runtime cache
directories are marked with the name of the architecture they target, so
for example "$(PWD)/build" becomes "$(PWD)/build_x64" (the same happens
to the cache directory name).
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit makes a minor change to the native module build scripts, to make the intermediate MPY file keep the same file name it will have once the final pre-processing step takes place. A MPY file will retain its file name as the first QSTR entry in the file, and before these changes the name being written would be the one used for the intermediate MPY output file (ie. "$BUILDDIR/$MODNAME.native.mpy"). The `mpy-tool.py` preprocessing pass would keep that string intact but rename the file, so things wouldn't match in error tracebacks. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit adds an option to the MPY linker to brand generated file with a custom internal file name rather than the raw output path provided in the command line. MPY files, as part of their preambles, will contain a path name as the first entry in the constant string pool. However that may contain unneeded data (ie. sometimes the plain file name is enough) or it may have sensitive data in there (if an alternate build path is provided it may contain product code names or client names which should probably not be disclosed). Until now there was no provision to let users use a different internal path name. A new option was added to `mpy_ld.py`: "--source-name" which, if passed, will write the given string in the module file. If said option is not provided, generated MPY files will still carry the raw command line output path but stripped of all leading path segments. The example natmod makefiles have been updated to always provide that option whenever the final file name on the filesystem wouldn't match the internal MPY file name. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
a59aebf to
f20c234
Compare
dpgeorge
approved these changes
Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR modifies the native modules build system to use different directories for different architectures.
Previously, the natmod build system would unconditionally put all build data into a single directory (usually "$(PWD)/build" unless overridden), and the static library runtime cache into another directory ("$(PWD)/.mpy_ld_cache"). That works if building is always done for a single architecture or if a full clean is performed before switching architectures, which sometimes is not wanted (collecting the runtime cache may take quite some time depending on the module complexity, for example).
With these changes, both the build directory and the runtime cache directories are marked with the name of the architecture they target, so for example "$(PWD)/build" becomes "$(PWD)/build_x64" (the same happens to the cache directory name).
That does not come without drawbacks unless the build directory name is overridden in the makefile. MPY files as part of their preambles will contain the path name provided to
mpy_ld.pyas the first entry in the constant string pool, meaning the output files will be a tiny bit larger. To offset this, a new option was added tompy_ld.py,--internal-filenamewhich - if passed - will write the given string in the module file instead of the default path name. If said option is not provided, generated MPY files will still carry the raw command line output path, maintaining the same behaviour as before these changes.That also lets advanced users shrink their MPY files even further (eg. by using single letter names) and/or hide potentially sensitive information provided by the path name if a custom directory is used and said directory contains things like product code names or client names.
This also closes #6585.
Testing
Besides manual testing performed both for native Unix and QEMU targets, this is should also be tested by CI.
Trade-offs and Alternatives
Users building a certain module for just one architecture should probably look into overriding the
BUILDvariable if a longer MPY file name is a deal-breaker, or provide their own shorter file name now that the possibility is there.Right now
mpy-tool.pydoes not have such a functionality for already-built MPY files. I had a quick look at it, but it may require more modifications than what I'm willing to add to this PR.Generative AI
I did not use generative AI tools when creating this PR.