Hi Andy,
Thank you for reaching out to us, and welcome to Embeetle!
The importer picks up many files that are in the sketchbook directory tree but ignored by Arduino’s build.
The Arduino importer basically runs the Arduino compiler on the original project with the --verbose flag to list all the required .c and .cpp files. Those are then copied into the Embeetle project. However, this doesn’t always cover all needed files. We’ve built in a few extra mechanisms to ensure everything is covered, and thereby play on the safe side. So you might indeed have a few more files in the project than absolutely necessary.
Over the years, our Embeetle Source Analyzer has improved, and we now do have the technology to be more selective in Arduino imports. In other words: we would now be able to refine the importer such that it ONLY selects the bare minimum of files you need for the project to compile. That would be a valid design choice - but comes with its own drawbacks. In the world of Arduino, people are used to some things just working out-of-the-box. You write a print-statement, so you want that to just work. For that, certain files have to be part of the project regardless of them being used or not in the Arduino sketch you start importing from.
That being said, I don’t want to shrug off your concerns just like that. Maybe our current importer has been too greedy, including files that are totally unnecessary? If that is the case, then it would be great if you could share the project and we look into it together.
filetree.mk is read-only and I thought that it was to be editable so that things like this could be fixed.
The way to change things in filetree.mk is by right-clicking the red and green checkmarks in the Filetree. All the source files get either a red or green checkmark in our Filetree, which indicates if the file is part of the project or not. If our Source Analyzer (our engine that parses the files in the background) makes a mistake there, you can overrule its decisions by clicking on the checkmarks in the Filetree and clicking “Force Include” or “Force Exclude”:
You will see that filetree.mk changes accordingly.
I apologize that this wasn’t clear. Our goal is to make Embeetle so intuitive that things like this are clear for anyone, without reading the manual. Good software is intuitive - no need for a manual. Maybe we should show a popup when a user tries to modify filetree.mk to clarify this? Popups are sometimes annoying though. What would have been the ideal way for you to intuitively feel this link between filetree.mk and the Filetree tab? I look forward to your suggestion on this matter.
There are a few problems that could be solved by embeetle not trying so hard to be helpful. One is the removal of what embeetle decided was a gratuitous extra wrapping of parens, for an expression that the author (not me) added to ensure that a macro worked correctly.
The removal of extra parenthesis wrappings is something we did for both our Arduino and CubeMX importers, because we got so many warnings from these projects. I wasn’t aware that this would break some macros. Thank you for bringing that to our attention!
Can you share the code snippet that has been affected by this? We can then fix it in our next release.
The other was crlf->lf transformation on some files, a gratuitous operation and one that kicked off a bunch of trivial git diff’s.
We’ve had problems in the past with the crlf and figured that giving all projects a linux-style line ending solved so many headaches.
I understand it’s annoying for you with the git diffs. I’ll check with my colleagues if we can figure something out here.
Aside from the git diffs - is there any other nuisance that the conversion from crlf->lf causes on your system?
Embeetle’s importer created concrete copies of the linked files and also copied in the directory they came from since I had a convenience link to it within the Arduino project folder, while the git repo of them is beside it.
What I would have preferred: copy links as links, with perhaps a notice that the target of the link is not getting copied.
In the early days of Embeetle, we set up a few “laws” or “principles” that we adhere to at all costs. One of these is the self-contained project principle: every Embeetle project has all of its files (source files, makefiles, linker scripts, openocd files, …) collected in a single folder. Of course that single folder can have subfolders to organize everything nicely. But you get the point:
if you share your project with a colleague or friend - just zip the folder and send it to him. It just works.
Your request to “copy links as links” would break that principle.
I do acknowledge that this practice comes with its downsides. You now have a library that’s duplicated in each of your Embeetle projects. Could Git help you out with this (making your own forks of the public repos)? Git submodules maybe? We should have a chat about this. It would be great to hear your thoughts on the matter.
Thank you Andy for sharing your concerns with us. I look forward to fix them together.
Can you give me a few moments you are available for a video call?
I live in central Texas, CST timezone.