Skip to content

Do not transfer source files during build #143

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

Closed
jeff-winn opened this issue Feb 8, 2019 · 2 comments
Closed

Do not transfer source files during build #143

jeff-winn opened this issue Feb 8, 2019 · 2 comments
Labels
conclusion: declined Will not be worked on topic: code Related to content of the project itself type: enhancement Proposed improvement

Comments

@jeff-winn
Copy link
Contributor

jeff-winn commented Feb 8, 2019

I'm not entirely sure why the source files are being transferred into a temporary folder rather than just referencing their original locations but this does have some impacts to how modern IDEs treat the errors that come out during the compilation process. The code for the screenshots below can be found on my GitHub profile here if you need a sample.

It could be something you had originally used to service your IDE, which may still be needed. If so, this mechanism should be kept inside your IDE and not within the CLI. But rather have the CLI simply pointed at your temporary build folder generated by your IDE.

When issues occur within the compilation process many IDEs use the information in the out stream and error stream and parse it out so they can report those issues back to the developer through some easier means of locating them. In this sample I've intentionally misspelt the name of an enum to exhibit what would show up within VS Code.

problem 1

You can see from the above screenshot that the compiler has detected the misspelling and reported it back to me. Normally I would simply be able to click on the link and it would take me directly to the file that caused the issue along with move me directly to the offending line to fix it.

problem 2

The above error depicts what happens indicating the file was not found (which given it's temporary that's not surprising). However worse would be editing that other copy of the code rather than the real copy that is being managed within source control.

Fixing this and not transferring the code to a separate folder to build there should let the IDEs report back and allow their interfaces to work in the way they were intended.

@jeff-winn jeff-winn changed the title Do not move source files during build Do not transfer source files during build Feb 8, 2019
@per1234 per1234 added the type: enhancement Proposed improvement label May 24, 2019
@cmaglie cmaglie added the topic: documentation Related to documentation for the project label Sep 12, 2019
@matthijskooijman
Copy link
Collaborator

This would be great, but is not quite trivial. The reason files are copied to a build directory, is that all .ino files are concatenated (together with generated forward declaration) and written to a single .cpp file. This file must live next to the other sketch files, so it must either be written into the sketch directory (which is impossible, the sketch directory might be read-only and you do not really want to write temp files into sketch directory anyway), or it must be written to a temp build directory and all other files must be copied alongside it.

This requirement is to allow the .ino files to include any source or header files living in the sketch directory. An obvious solution would be to simply add an -I option to the sketch directory, but then the difference between #include "foo.h" and #include <foo.h> breaks. There are some other options that seem useful here, but I was not able to figure out a way to really make this work (I can't remember the details, but IIRC there was a way where includes from the .ino file worked, but then includes from other files broke, or something like that).

Note that the Java IDE might do another copy of your sketch if you have saved changes, to allow compiling your unsaved changes without overwriting any data.

A somewhat (but not quite) related issue is arduino/arduino-builder#86

@jeff-winn
Copy link
Contributor Author

Unfortunate but not unexpected, going to close.

per1234 added a commit that referenced this issue Aug 9, 2021
Allow incomplete hidden board definitions
@per1234 per1234 added conclusion: declined Will not be worked on topic: code Related to content of the project itself and removed topic: documentation Related to documentation for the project labels Jan 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conclusion: declined Will not be worked on topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Development

No branches or pull requests

4 participants