-
-
Notifications
You must be signed in to change notification settings - Fork 384
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
Refined the definition of build_cache.path
and the --build-path
behaviour
#2673
Conversation
Ok, besides some (no more valid) tests that are failing, one thing that I noticed is that now the commands |
Thought exercise: Given this new behavior, would it make sense to eliminate/deprecate setting the build cache path entirely? (Do |
Actually, they have it, it's not called
as you can see the
I agree, but I'd rather deprecate only the command line flag |
cf0b370
to
b4a05c1
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2673 +/- ##
=======================================
Coverage 67.67% 67.68%
=======================================
Files 234 234
Lines 22207 22226 +19
=======================================
+ Hits 15028 15043 +15
- Misses 5998 6001 +3
- Partials 1181 1182 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I've also performed some tests to see if we have some edgy cases when using build-cache-extra-paths, but everything went fine. Plus we already added extensive integration tests in that area so I'm extra confident. 💪
The complete build will be performed in the specified build path. The build artifacts in the build path will be reused for the next build.
Previously it would reject only if ALL the arguments in the given set are used. Now it rejects if AT LEAST TWO arguments of the given set are used.
8e8d7ac
to
ec3a9cd
Compare
Yay!!! |
Please check if the PR fulfills these requirements
See how to contribute
before creating one)
our contributing guidelines
UPGRADING.md
has been updated with a migration guide (for breaking changes)configuration.schema.json
updated if new parameters are added.What kind of change does this PR introduce?
build_cache.path
(and--build-cache-path
).--build-path
is set by the user: in this case, the build cache is no longer used and the build is based only on the object files found in the build pathUPDATES
After a bit more discussion in this PR, we agreed to also:
--build-cache-path
parameter from thecompile
command (it's now hidden and now useless, but we'll keep it working for backward compatibility)--build-path
flag toupload --build-path
anddebug --build-path
commands to pair with thecompile --build-path
command.$TMP/arduino
to the User cache folder (as defined by each OS, for example on Linux appears to be$HOME/.cache/arduino
).What is the current behavior?
build_cache.path
setting (and consequently the--build-cache-path
flag) specified the path of the platforms' cores cache (it will be in{build_cache.path}/cores
). The default{build_cache.path}
is/tmp/arduino
, so the default core cache is in/tmp/arduino/cores
. Instead, the temporary sketch cache was always in the default/tmp/arduino/sketches
regardless of the setting.--build-path
, an already-built core found in the core cache path could be used to speed up the build.Let's see some examples to clarify:
In the example above:
/tmp/arduino/sketches
(even if we specified to use a build cache dir in../cache
)../cache
dir (not really a bug, but since we asked to use a specific build-path the global cache should be completely ignored)In the example above, after removing
/tmp/arduino/
, we made a new build by setting both the cache dir and the build dir:../cache
dir has been used to avoid rebuilding the core (since we asked to use a specific build-path the external cache should not be used)--build-path
to~/Arduino/Blink/build
has been used insteadFinally, in the example above, after wiping the custom
../cache
dir:../cache/cores
(instead of ignoring the cache)What is the new behavior?
build_cache.path
(and--build-cache-path
) is now used to set the cache dir for both the cores and sketches.--build-path
will now disable all caches, this means that the platform core is rebuilt in the build path (and possibly reused for the next build if the--build-path
remains the same).Let's see the same examples as before:
As we can see in this case:
../cache
now contains both the cores and the sketchesIn this case:
../cache
This example shows that:
✅ the build cache is completely ignored if a user-defined build path is used, in fact, neither
/tmp/arduino/
nor../cache
were created.Does this PR introduce a breaking change, and is titled accordingly?
I'm unsure if this PR can be considered a breaking change, AFAICS in the worst-case scenario, this PR could cause a slower build time because the core may be rebuilt even if an already built one is in the build cache. On the other hand, the build now relies only on the build path provided by the user, which is a better outcome IMHO.
I may be missing some obscure use cases that this PR breaks, but strictly speaking, it won't break any public API.
Other information
/cc @egnor