Support for multiple build targets in Sloeber

[baudhuina]

Preliminary remark: The best news would obviously be that I completely missed a « multiple-target » feature in Sloeber and this issue is pointless… Please let me know if this is the case.

Context
My code base includes a large number of classes (.h/.cpp couples in various libraries) and a number of .ino files, each one with its setup() and loop() functions, each one corresponding to a sketch: I have a distributed system with several boards running different code on different hardware, and many unit- and integration-tests, each one a « sketch » in Arduino terminology.

In the ArduinoIDE, I obviously open the .ino file I want, anywhere in my source tree, and build the corresponding executable. Although highly inefficient, compile-wise, it works reliably.

In Eclipse, I would achieve the same in a standard C/C++ project, using a Makefile project, and defining several targets (Ecplise documentation states that multiple targets cannot be supported with Managed makefiles). I understand from #1397 that Sloeber provides a makefile generator, that makefiles are recreated at each build, and that Makefile projects are consequently not an option, unless I do not use Sloeber’s Sketch projects at all, which defeats the purpose.

My understanding of the current behavior of Sloeber
I understand that when building, without diverging from the default configuration:

• A sloeber.ino.cpp wrapper files created in the project directory, which includes all .ino files found in the project folder (and only in the project folder).

• The wrapper is created, compiled and linked as part of the recipe for the default build target.

This means that:

• More than one sketch file in the project directory causes the link to fails if each .ino is a different sketch (at least because of the multiple definitions of setup() and loop()). This is not a real issue, since ArduinoIDE always enforced a separate folder for each .ino file, so it would not be good idea, compatibility-wise, to have multiple sketches in a single directory. I understand this is because some people have sketches consisting of more than one .ino file (example here: https://forum.arduino.cc/t/how-can-one-load-an-ino-file-from-arduino-ide-into-eclipse-sloeber/616078). I’ve always assumed that "1 sketch = 1 ino file", and that "every .ino file contains at least the setup() and loop() functions", but why not.

• .ino files located anywhere else in a source folder are ignored (much more an issue, at least to me).

If I’m correct so far, supporting multiple build targets, or at least use .ino files located within a source folder, would mean either:

• To be able to configure the folder from which .ino files are included by the wrapper (default_target_folder?). Is that currently possible? It would allow for using .ino files located anywhere, but still would require to update the project configuration whenever switching to another target, which is better but not great.

• To be able to configure exactly which .ino file to include in the wrapper (same impact and limitation, great to enforce the « 1 ino = 1 sketch » principle, but probably not optimal to support the « 1 sketch = several ino » paradigm described above).

• To create additional makefile targets for the sketches associated with .ino files not located in the project folder. This can be achieved:

1. Manually, by creating a $(PROJECT_LOC)/makefile.targets . This seems to be inline with the Eclipse philosophy, and supported by the current makefile generator, since makefile.targets is indeed included by the generated makefile. It is currently not possible because the dependency to sloeber.ino.cpp is in the general dependencies, while it should not be in the dependencies of any of those new targets. It also seems the sloeber.ino.cpp creation happens outside of the makefile, while the new targets should be able to include the creating a wrapper for their own .ino file as part of their recipe. Restructuring the makefile to make this possible is likely to be as complicated as implementing the automatic approach below (which would be much better).
2. Automatically: by having the makefile generator scan the source folders for .ino files, and create a makefile target for each of them, which would create the corresponding wrapper in the project folder. Build targets could then be standardly configured in Eclipse and any subset of them could be built, without any further change in the project configuration. This seems to me like the real solution, hopefully even not too complex, and backward compatible if the default target remains the one involving the .ino files from the project folder (or from the default_target_folder, if such a setting would exist).

NB:

• What would still not be addressed is having different hardware for different targets. Definitely a real situation for a project running on a number of boards, not all with the same hardware, but my understanding is that Eclipse does not support that : Selecting a « Build Configuration » sets a context in which the makefile generation happens, having multi-configuration makefiles seems to be a case for custom makefiles. A decent solution at zero-cost would be to create compound targets in $(PROJECT_LOC)/ makefile.targets to have 1 target to build all targets for an each Configuration. Then select a particular build configuration A, and build target « all_sketches_on_hardware_A.

• If the documentation about the information I collected above is indeed missing or partial, I’ll be more than happy to write and share it once my understanding is confirmed and a preferred way to handle multiple build target has been identified.

[jantje]

Just some thoughts

completely missed a « multiple-target » feature in Sloeber ....

Apparently you did. The newest Sloeber uses target to burn the bootloader and so on.

... and this issue is pointless

I'm not fully understanding yet what you are trying to do but saying the issue is pointless is probably wrong.

In the ArduinoIDE, I obviously open the .ino file I want, anywhere in my source tree, and build the corresponding executable. Although highly inefficient, compile-wise, it works reliably.

This statement is not half as clear as you think it is.

In Eclipse, I would achieve the same in a standard C/C++ project, using a Makefile project, and defining several targets

Why not use multiple projects? A project for each board/node type in your distributed system? As Sloeber links the hardware to the code in the project; different hardware means different projects or different configurations or changing the hardware all the time.

I’ve always assumed that "1 sketch = 1 ino file", and that "every .ino file contains at least the setup() and loop() functions"

Plenty of years ago I did so as well. But no a ino file is just a java like c++ file. For Arduino IDE a sketch must contain at least 1 ino file. Sloeber does not need a ino file.

A sloeber.ino.cpp wrapper files created in the project directory, which includes all .ino files found in the project folder (and only in the project folder).

The sloeber.ino.cpp file is a way to convert ino files in cpp files in sutch a way that CDT works as smooth as possible. The best way is not to use .ino files.
The "only in the project folder" will probably be fixed some day.

What would still not be addressed is having different hardware for different targets. Definitely a real situation for a project running on a number of boards, not all with the same hardware, but my understanding is that Eclipse does not support that

Sloeber/CDT supports multiple project and each project supports multiple configurations.
Each configuration can have different hardware.
I advice using different configurations in a project if you want the same/similar code to run on different platforms/hardware.
I advice to use different projects if the code is significant differently.

[baudhuina]

My, you're quick...
A few clarification on your thoughts, I'll integrate the clarifications and conclusions in a revised version of my original text when we're sure we understand each other.

completely missed a « multiple-target » feature in Sloeber ....

Apparently you did. The newest Sloeber uses target to burn the bootloader and so on.

Ok, that was an unclear statement, sorry. I fully understand you use several targets in your makefile, what I meant was: when the source folders include code for several different binaries (basically several setup()/loop() definitions, usually each pair in a .ino file, but it could be in any ino/cpp file), there is no target in the makefile to build each of them, nor (as far as I understand) an easy way for the user to add them.

... and this issue is pointless
I'm not fully understanding yet what you are trying to do but saying the issue is pointless is probably wrong.

Just trying to be modest and acknowledging the fact that I could be wrong all the way. Was probably wrong saying so, indeed. Unless I'm wrong saying it now?

In the ArduinoIDE, I obviously open the .ino file I want, anywhere in my source tree, and build the corresponding executable. Although highly inefficient, compile-wise, it works reliably.
This statement is not half as clear as you think it is.

I can see that :-) . Let me clarify... Let's think of a large but well organised source tree, the root of which is in ArduinoIDE the "root of the sketchbook". This tree includes:

• classes used by several nodes in a distributed system,
• for each node named xxx, a folders xxx containing a xxx.ino file, and possibly a few source files used only by node xxx. Typically, files in such a folder are just a few lines, since most of the code is implemented by classes shared by several nodes. Differences between 2 different nodes can be as tiny as a single argument value in a constructor call.
• for each test program named ttt, a folders ttt containing a ttt.ino file and possibly a few source files used only by test ttt (typically the test cases definitions, if they are not shared between several test programs).
• A libraries/ folder that makes ArduinoIDE perfectly happy to compile sketch xxx or ttt (how to use or not reuse it in a Sloeber project is an important but unrelated issue).

In ArduinoIDE (or CLI), every xxx or ttt folder is a sketch. I can open any of them and build them. Each of them will recompile every bit of the shared code, every time I build a different sketch, even on the same board, because there is no concept larger that the sketch in Arduino. It is annoyingly inefficient, especially given that there is almost only shared code in the system but it works reliably.

For many reasons I cannot diverge from a source code organisation that ArduinoIDE can handle, so this structure is the one I'm trying to get to work with in a Sloeber project, with no more change than project configuration (content filters etc..).

In Eclipse, I would achieve the same in a standard C/C++ project, using a Makefile project, and defining several targets
Why not use multiple projects? A project for each board/node type in your distributed system? As Sloeber links the hardware to the code in the project; different hardware means different projects or different configurations or changing the hardware all the time.

That, I could have explained, but I was already worried by the length of my post. I've explored this option, and here are a couple or reasons I concluded it was not a good solution:

1. I currently have 4 boards, and 7 different nodes and several dozens test programs, which makes 4 x 50 = 200 combinations. Not all boards are used on all nodes but even if it would means 100 projects, it does not seems optimal.
2. Our system is actually 90% core classes and 10% node/test specific code. It really feels like one project, not 100.
3. In my experience, configuring a project (Sloeber or plain CDT) is something incremental, adding content filters to exclude an example folder here, adding an include path here... Nothing complex or excessive, but definetely not something we want to synchronize manually over 100 projects.
4. Eclipse projects (or IDE settings in general) are typically not part of the project source repository. So far, our philosophy is that each developer checks-out a repo and follows a reasonably simple procedure to configure a project in his favourite IDE. Configuring and maintaining 100 projects... will not feel reasonably simple I'm afraid.
5. Any change in our code base, outside the very limited part which is node-specific will need unit- and integration- testing, which means rebuilding all binaries. I'll be happy to issue a different build command for each hardware used (4 commands), much less to have to trigger a build in 100 projects.
6. The case of a single code-base used to generate a set of binaries is described in the CDT Forums and I remember that the guideline was fairly consistent: use a single Standard Make project if your code is mostly common to all binaries or several Managed Make projects if not. I'm definitely in the first case.

To be complete, I've also briefly considered Eclipse Working Set's to group projects, but I'm not sure it was ever the idea to use them manage such large number of projects.

I’ve always assumed that "1 sketch = 1 ino file", and that "every .ino file contains at least the setup() and loop() functions"

Plenty of years ago I did so as well. But no a ino file is just a java like c++ file. For Arduino IDE a sketch must contain at least 1 ino file. Sloeber does not need a ino file.

I understand that, and I don't have any issue with that. I'll stick to the "1 sketch = 1 ino file" for the compatibility with AruinoIDE, but I understand Sloeber does not need to enforce it, and even needs to be more flexible to support other structures.

What would still not be addressed is having different hardware for different targets. Definitely a real situation for a project running on a number of boards, not all with the same hardware, but my understanding is that Eclipse does not support that

Sloeber/CDT supports multiple project and each project supports multiple configurations. Each configuration can have different hardware. I advice using different configurations in a project if you want the same/similar code to run on different platforms/hardware. I advice to use different projects if the code is significant differently.

I fully agree. My situation is that the code does not significantly differ (most of it is common), so I was going for 1 project

• with several configurations to cover the hardware variants
• with several "sketch mains" (globals+setup()+loop()), which in my case is a .ino file, but could be in any source.
  My whole concern was about handline the "several sketch mains" part...

I realise now that the idea that the makefile generator could detect each "sketch main" assuming it always materialize as .ino file is simplistic. I guess we would need to identify source files as "sketch mains" is some more flexible way, and then have those source:

• not included in the general project dependencies,
• be a dependency for a specific target only.
  Eg.
• xxx.ino should not be a general dependency for the project, just for the makefile target xxx which builds the binary for node xxx.
• ttt.ino should not be a general dependency for the project, just for the makefile target ttt which builds the binary for test ttt.

Do I make sense? I hope it clarifies the rationale for the 2 approaches ("manually" and "automatically") described in the end of my original post, which I cannot see how to put to use with the current makefile generator.

God, this is awfully long post, again...

[jantje]

Honestly, I think a conf call would be easier.
I seem to sense a misunderstanding of some eclipse terminology which would be easier to solve when talking than writing.

Let me breakdown the following qoute

I can see that :-) . Let me clarify... Let's think of a large but well organised source tree, the root of which is in ArduinoIDE the "root of the sketchbook". This tree includes:

    classes used by several nodes in a distributed system,
    for each node named xxx, a folders xxx containing a xxx.ino file, and possibly a few source files used only by node xxx. Typically, files in such a folder are just a few lines, since most of the code is implemented by classes shared by several nodes. Differences between 2 different nodes can be as tiny as a single argument value in a constructor call.
    for each test program named ttt, a folders ttt containing a ttt.ino file and possibly a few source files used only by test ttt (typically the test cases definitions, if they are not shared between several test programs).
    A libraries/ folder that makes ArduinoIDE perfectly happy to compile sketch xxx or ttt (how to use or not reuse it in a Sloeber project is an important but unrelated issue).

In Sloeber world the Arduino root would be the workspace.
The classes used by several nodes (I don't know why it is not a library) would be a eclipse project of any type (I mean it does not have to be a Sloeber project and it is probably just a general eclipse project).
For each node named xxx, a folder xxx containing a xxx.ino file would be your Sloeber projects
A libraries/ folder again probably a general eclipse project
for each test program named ttt, a folder ttt These folders may be Sloeber project but I do not yet know the nature of these test so I can't tell for sure. If these tests are sketches you upload to a Arduino they could be Sloeber projects (they may also be made on the fly based on examples of the libraries and as such not exists as folders in your version control repository)

So to me there is a match here to your current folder structure and how I would do it in Sloeber except maybe for the testing folders.

And talking about testing I read
Any change in our code base, outside the very limited part which is node-specific will need unit- and integration- testing, which means rebuilding all binaries. I'll be happy to issue a different build command for each hardware used (4 commands), much less to have to trigger a build in 100 projects.
If you need so many builds I would advise to automate the release and testing management. Eclipse support junit which integrates with Sloeber functionality and allows for data driven testing (now your board is a data entry and not even a configuration)
For example
Sloeber builds 1000 of arduino projects before release by a simple run test command. https://github.com/Sloeber/arduino-eclipse-plugin/blob/master/io.sloeber.tests/src/io/sloeber/core/CreateAndCompileArduinoIDEExamplesOnAVRHardwareTest.java

I also have a test https://github.com/Sloeber/arduino-eclipse-plugin/blob/master/io.sloeber.tests/src/io/sloeber/core/CompileAndUpload.java that builds a couple of arduino sketches (different hardware) uploads the sketch to the board and reads the serial port to verify the sketch was uploaded correctly. Again from a single click. The hardest part here is the serial port management which is purely OS stuff.

And to show how powerfull this stuff is: The Sloeber build running in github actions (so somewhere on the cloud) runs testing that involves creation and compilation of arduino sketches.

The only real problem is the library management. If Sloeber finds the right library for the right boards (gets really difficult when you have ethernet libraries installed and use ESP boards) your test/build should nearly always run fine

In my experience, configuring a project (Sloeber or plain CDT) is something incremental, adding content filters to exclude an example folder here, adding an include path here

In my experience an "existing codebase" should not have these needs (except for library management which I advice to keep under strict control in a big project).

[baudhuina]

Aaah ok... I never considered the workspace to be the "equivalent" of the sketchbook, and using different workspaces whenever I use a different sketchbook root in Arduino. It indeed makes sense and opens new possibilities. I'll reconsider my organisation with this in mind and be back (most likely with a few days or a week delay due to personal constraints).
Thanks for the suggestion of a conf call: I'll keep that in mind as well if I can't figure how to put your suggestions to work (but will try my best not to abuse your time).

[baudhuina]

So, you were perfectly right, I was misunderstanding some eclipse terminology and misusing the workspace vs. project concept: matching the Arduino Sketchbook with the Eclipse Workspace, and having a single folder as linked resource in a project, rather than the whole sketchbook, indeed solves almost all my issues. So, thanks for your patience!

This post replaces the original one, remaining issues at the end.

Context
We have a large project, so far built using ArduinoIDE and ArduinoCLI. Everything located under the Arduino "sketchbook root" is part of our project GIT repository. The /libraries folder contains a mix of libraries developed for our project (almost all our code is in libraries and shared by several sketches) and third-party libraries, installed either from zip files or through the Arduino Library Manager.

We want to develop/debug/build with Sloeber, while preserving the sketchbook structure to keep compatibility with ArduinoIDE and ArduinoCLI.

What we do

1. Initialize a Sloeber workspace for the sketchbook

• Check out the Git project repository anywhere on a local disk (but not in any folder used by Eclipse as workspace). It contains the root of the Sketchbook when using ArduineIDE (let the path to this folder be SKETCHBOOK_ROOT):

• Create a workspace anywhere on your local disk (not in the project working copy). Let the path to the workspace folder be WORKSPACE_LOC.

2. in Preferences/Sloeber/Library manager:

• Add SKETCHBOOK_ROOT/libraries as Private Library Path (this will allow to import libraries from there, and existing libraries will be imported by default).

• If there is a SKETCHBOOK_ROOT/hardware folder, add it as Private Harwdare Path (this should allow to use custom hardware if any is used) (currently not tested).

3. In Preferences/Sloeber/Third party index url’s:

• Add the URL to the third-party board indexes needed. In our case: https://adafruit.github.io/arduino-board-index/package_adafruit_index.json

4. In Preferences/Sloeber/Platform and boards:

• Activate the required platforms, to make the corresponding boards available in all projects.

5. For each sketch in the sketchbook:

• Identify the sketch to build. We assume that all sketch-specific elements (at the very least some globals, the setup() and the loop() methods) are in a set of .ino and .cpp files all in the same folder, e.g. SKETCHBOOK_ROOT/aFolder/anotherFolder/theFolderContainingMySketch. Let the path to this folder be SKETCH_ROOT.

• Create an “Arduino sketch” project in the workspace, with (i) the appropriate board and (ii) No file, since the sketch is present in the repository. Let this project (which is not in the GIT working copy) location be PROJECT_LOC

• Add SKETCH_ROOT as source folder (linked resource) for the sketch (sources are not copied in the project folder).

• Create symbolic link(s) in the eclipse project folder, to the .ino file(s) found in SKETCH_ROOT (we always have a single .ino file per sketch, but this would work if no .ino or multiple .ino files are used).
  ln -s $SKETCH_ROOT/*.ino $PROJECT_LOC

• Build. No problem.

• Edit library (from any Sloeber project): no problem

• Edit sketch: no problem.

Issues

• (MAJOR) How to avoid the need for the symlink(s), which feels like an unsatisfactory workaround? Could we have a project property to define the folder to explore for .ino files to be wrapped in a cpp file(s) and included in the project? It would be the "sketch folder", could default to PROJECT_LOC, but be configurable during the project creation or in the properties dialog. Note: cpp wrappers would still have to be generated in PROJECT_LOC, not in SKETCH_ROOT where they would be visible by ArduinoIDE. I briefly considered to create them in SKETCH_ROOT, manually, rather than symlinking: it works for Sloeber, but breaks the compatibility with ArduinoIDE/CLI which uses both the .ino and the wrapper, and fails to link because of duplicate symbols, as expected.
• (MINOR) How to distinguish between libs from Private Library Path and others libs? The "Import Library Dialog" in Sloeber presents a unified list which is not very lisible, especially when a library can be imported either from the private path, or from an external repo.

[jantje]

Why not import the git repository in eclipse?

[baudhuina]

For many not so good reasons: - I didn’t think of doing it, since the repo was already cloned, and it was easy to just create a Linked Resource on one of its folders. - the repo contains the code for other parts of the system which are not embedded, eg. Python code for system administration apps running on computers, developed using other IDEs (e.g PyCharm). There isn’t anything relevant for ArduinoIDE/CLI (and I guess not for Sloeber either) outside the tree rooted at Sketchbook root. So, we check out the repo once, and access it with whatever tools we need: Arduino/Sloeber, PyCharm, Web editors, etc. But I probably could have imported the folders I need as easily. - I’m not clear about what it means to « import projects from GIT » in the eclipse terminology: I always assumed that this meant an Eclipse project was part of the repo, which is not the case for my repo. Just tried now: « Import existing Eclipse projects » complains that there is no project to be found (there aren’t any indeed), « Import using the New Project wizard » allows me to create a Sketchbook project but it has 0 libraries in the Select Arduino Libraries dialog (no standard library to select, no library to select from the Private Library Path configured in the workspace). There is also no Sloeber category in the project preferences? I definitely do not understand the concept of importing projects from GIT…. - we are used to SourceTree as a GIT client, which makes it unnecessary to master the interface of the GIT plugin in each IDE we use (although, I’ve been using the eclipse GIT plugin to commit changes done in Eclipse, from within eclipse while the working copy was otherwise used through SourceTree: that’s perfectly ok as well). None of this is reason enough not to consider another option, but what would be improved by importing in eclipse? Le 16 mai 2023 à 23:40, jantje ***@***.***> a écrit : Why not import the git repository in eclipse? — Reply to this email directly, view it on GitHub <#1566 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNAEZB6LULR72XGGK57DC3XGPX55ANCNFSM6AAAAAAYBH6QTM>. You are receiving this because you authored the thread.

[jantje]

• I didn’t think of doing it, since the repo was already cloned, and it was easy to just create a Linked Resource on one of its folders.

Whether the git repository is already cloned or not does not matter for eclipse (IMHO it even works better when the repository is already cloned)

• the repo contains the code for other parts of the system which are not embedded, eg. Python code for system administration apps running on computers, developed using other IDEs (e.g PyCharm). There isn’t anything relevant for ArduinoIDE/CLI (and I guess not for Sloeber either) outside the tree rooted at Sketchbook root. So, we check out the repo once, and access it with whatever tools we need: Arduino/Sloeber, PyCharm, Web editors, etc. But I probably could have imported the folders I need as easily.

In this case I would have used the Sketchbook as my workspace folder.

I’m not clear about what it means to « import projects from GIT » in the eclipse terminology: I always assumed that this meant an Eclipse project was part of the repo, which is not the case for my repo.

There are more things that are not clear to me than there are thing that are clear to me 😎 The git import is not so clear as well.
But basically when you import a git repository eclipse will show all subfolders (if you need to clone you need to do back after the cloning is done) and you can select which folders to import.
I import as standard eclipse project and then use Sloeber->convert to Sloeber project

Import using the New Project wizard » allows me to create a Sketchbook project but it has 0 libraries in the Select Arduino Libraries dialog (no standard library to select, no library to select from the Private Library Path configured in the workspace). There is also no Sloeber category in the project preferences? I definitely do not understand the concept of importing projects from GIT…

You impress me. I never succeeded in getting the import using New project wizard to work.
Sloeber is a eclipse plugin just like the java ide and CDT. This means you can have java projects and CDT projects and python projects all in the same eclipse workspace (if you have the plugins installed).
So if you have a general eclipse project eclipse does not see it as a Sloeber project. That is why there is the "convert to Sloeber project"

I think you have plenty of reasons not to use git import.

As to the issues
The symlink would be a no-go for me.
It is a simple change I never got to do as I see ino files support purely for examples. Sloeber support for ino files is not as good as Arduino IDE. The change needed is here:

arduino-eclipse-plugin/io.sloeber.core/src/io/sloeber/core/tools/PdePreprocessor.java

Line 71 in fb9fa72

allResources.addAll(Arrays.asList(iProject.members(0)));

Pretty crappy code if you ask me 😉
It should become a project visitor.

For your library questions: see #1537

[baudhuina]

As to the issues The symlink would be a no-go for me.

Oh, perhaps I wasn’t clear: I was not suggesting anything involving symlinks, which are the only workaround I could think of so far, and a crappy solution indeed. I would welcome any solution to have either Sloeber ’see’ the ino files where it expects to find them or have Sloeber look for them where they actually are. Your statement "It is a simple change I never got to do as I see ino files support purely for examples. » was all I needed to see how to have that (I can be slow, I know…)! In fact, what I need is exactly what Sloeber provides for examples: a linked resource (or several of them in case of multiple inos) which is a file rather than a folder so Sloeber finds the .ino(s) at the project root without duplicating anything in the Project folder, and without me installing symlinks in the file system. So I can just drag the .ino file to the project (from Explorer to Sloeber) and avoid installing the symlink in the file system! If I import my repo as a General Project in Eclipse I can even install the resource within Eclipse with an option-drag from repo to the Sketch project root (that’s a very good reason to import the repo, after all!). That’s the solution I was looking for!! Now, we could dream of avoiding the unnecessary step of creating a project without an .ino file before adding the Linked Resource(s)... Would you consider having in an extra option in the project creation Wizard? In addition to: No file, Default ino, Default cpp, Custom template and Sample Sketch, how about an option « Existing sketch » to allow to select a folder in the file system or in an imported GIT repo? The wizard would then handle it exactly as the directory of a sample sketch (provided you support mutlifile sample sketches?): - install each .ino as a linked resource at the project root, - install the folder a linked resource so possible additional .cpp files are included in the build as well. « Sample sketch" would then just be a specific case of « Existing sketch » for which the user can more efficiently be presented with the available sketches. Alain PS1: Could I challenge your restrictive view of the usefulness of .ino support? It seems to me that it is also key to compatibility with Arduino IDE, which can be a mandatory requirement. In my context for example, I have some fairly large sketchbooks to which some contributors are high-school students participating in projects like the Cansat contest by the European Space Agency. I cannot possibly expect all of them to have the necessary skills to work with Eclipse, although reviewing and debugging their code is soooo much easier for me using Sloeber. Not being able to have a single repo from which I can build from both ArduinoIDE and Sloeber would be a show-killer for Sloeber. PS: I’m afraid this thread is becoming a mess and will not be very usable for anybody else in the future… Would it be helpful if I would write a « How to work with an existing Arduino Sketchbook in Sloeber, and preserve the Arduino compatibility » page with the substance of what I’m learning here, which could complement the HowTos of the website? If so, what’s the most convenient way of contributing?

[jantje]

In addition to: No file, Default ino, Default cpp, Custom template and Sample Sketch, how about an option « Existing sketch » to allow to select a folder in the file system or in an imported GIT repo? The wizard would then handle it exactly as the directory of a sample sketch (provided you support mutlifile sample sketches?):

If you create a project with default ino and the [projectname].ino file already exists behaves like I understand your request.
This is to import existing projects.

Could I challenge your restrictive view of the usefulness of .ino support? It seems to me that it is also key to compatibility with Arduino IDE, which can be a mandatory requirement.

The problem is technical difficulty. Sloeber basically provides CDT with Arduino framework capabilities but in the end it is CDT that does the compiling and error reporting.
Arduino IDE copies the sketch files to a different location and modifies the ino files.
Copying files before building is not a CDT supported feature. Problems arise when reporting back issues and with the code analysis.
To work around that I generate the sloeber.ino.cpp file that does the method declarations and so on and includes the ino files.
This does however mean that

1. includes in the ino files are also included in sloeber.ino.cpp (needed for the added declarations to work)
2. Methods using classes/enums do not work in this way (double declarations or missing declarations)
3. CDT is not aware of this way of working so the code analyses can/will generate errors/warning.

To work around these issues:
1)Sloeber adds #pragma once to all installed header files by default (option that can be turned of)
I only know 1 rare use case where this cause problems.
2a) I tell people "I see ino files support purely for examples"
2b) You can work around this using header files (making the code work both in Arduino ide and Sloeber)
3) There is no solution. There are 2 cases where this is a annoying thing.
a) The simple example (not having any headers and as such not having arduino.h include and missing all declarations)
b) The multiple ino project. All methods implemented in the other ino files are unknow to the code analyser.
A is not the target of Sloeber and simply adding arduino.h will satisfy the code analyser
For b I would advice to use .cpp files for the extra .ino files. That is compliant with arduino ide and the CDT refactoring capabilities make maintaining header files no big deal.
For the project you originally talked about this all should work fine.

I have some fairly large sketchbooks to which some contributors are high-school students participating in projects like the Cansat contest by the European Space Agency.

It is hard to predict what this will be like, though in most cases -if you understand the limitations and how to work around them- there are easy work arounds. If there are consistent issues which can not be fixed in the sloeber.ino.cpp solution we can look at implementing eclipse quick fixes (hover over the issue and select the way to resolve the issue).

PS: I’m afraid this thread is becoming a mess and will not be very usable for anybody else in the future… Would it be helpful if I would write a « How to work with an existing Arduino Sketchbook in Sloeber, and preserve the Arduino compatibility » page with the substance of what I’m learning here, which could complement the HowTos of the website? If so, what’s the most convenient way of contributing?

Most of the things we have been discussing here are not purely Sloeber but eclipse. Also things change all the time and maintaining documentation is painfull. (as the link to my own post on this page makes very clear http://eclipse.baeyens.it/how_to.shtml#/l)
If you want to do a write up I would advice an article titled « How I work with an existing Arduino Sketchbook in Sloeber, and preserve the Arduino compatibility ».
The article can be in the discussion section here or a link to anywhere of your likings will do 😄

[jantje]

You may not have noticed but having the sloeber.ino.cpp in you sketch folder is not a problem for arduino ide as the whole file is ifdefed with IN_ECLIPSE which is not defined in arduino ide.
As a consequence the sloeber.ino.cpp file is conceptually completely ignored by arduino ide.

[baudhuina]

You may not have noticed but having the sloeber.ino.cpp in you sketch folder is not a problem for arduino ide as the whole file is ifdefed with IN_ECLIPSE which is not defined in arduino ide. As a consequence the sloeber.ino.cpp file is conceptually completely ignored by arduino ide.

Oh, I noticed, even tried it, and it works… Was my workaround at some point, just discovered the linked resource workaround in the meantime. The choice is finally between: - Polluting my source tree with unnecessary sources, which will raise questions and open an unnecessary tab in front of the ArduinoIDE users (i.e. the very people I cannot expect to understand the intricacies of Eclise/Sloeber vs. Arduino); - Using Eclipse linked resources to provide a very reasonable solution to Eclipse/Sloever issues, which will be transparent to the Arduino users. … this is not a though choice :-)

In addition to: No file, Default ino, Default cpp, Custom template and Sample Sketch, how about an option « Existing sketch » to allow to select a folder in the file system or in an imported GIT repo? The wizard would then handle it exactly as the directory of a sample sketch (provided you support mutlifile sample sketches?): If you create a project with default ino and the [projectname].ino file already exists behaves like I understand your request. This is to import existing projects.

Mmmh, if I’m understanding this right, this (fairly hard to guess) feature, is for importing existing projects with an [projectname].ino file in eclipse the project folder. Which is definitely not the case when working with an Arduino Sketchbook. If my suggestion for the wizard does not seem inline with Sloeber philosophy, technically feasible, or not reasonable, given that the .ino support is limited, I can hear it. It could indeed raise the expectation for a more complete support of ino files which is probably not a priority. As far as I’m concerned, if the project wizard cannot help me install the linked resources in the most user-friendly way, I can live with that. I’m also more than happy with the current level of support of ino. As for the writing, I do not really *want* to do a write up, but since I’m doing it anyway for the development guidelines of my own projects, I would be happy to make it a bit more general **if it helps and can reciprocate some of the time you spent educating me**. Definitely not if it make your life more difficult maintaining the information! Thanks again for your dedication and reactivity, Alain. Le 17 mai 2023 à 15:53, jantje ***@***.***> a écrit : — Reply to this email directly, view it on GitHub <#1566 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNAEZBJFQPXKOFT7XITNHDXGTJ6BANCNFSM6AAAAAAYBH6QTM>. You are receiving this because you authored the thread.

[jantje]

Polluting my source tree with unnecessary sources, which will raise questions and open an unnecessary tab in front of the ArduinoIDE users (i.e. the very people I cannot expect to understand the intricacies of Eclise/Sloeber vs. Arduino);

Unless you are talking about other people working on your system or you giving demo's I do not see a problem.
If you share using version control there is no need to pollute other peoples folders.
Sloeber marks sloeber.ino.cpp as derived so when using eclipse git it is ignored (I don't know how this works)
But adding sloeber.ino.cpp to the .ignore works just as well. If you use the folders directly you will also need to add the build folders to the .ignore file. Library and core folders are linked at the eclipse level so are not visible to git.

Mmmh, if I’m understanding this right, this (fairly hard to guess) feature, is for importing existing projects with an [projectname].ino file in eclipse the project folder. Which is definitely not the case when working with an Arduino Sketchbook.

I think we are cross talking. A call would be easier

Thanks again for your dedication and reactivity,

It seems to me that your use case it what I build Sloeber for. It is a steep learning curve so I know some help is welcome.

[baudhuina]

I think we are cross talking. A call would be easier Agreed. Possible for me on Saturday, any time 5 to 8 pm, or Sunday any time from 5 pm. Any convient times for you in those slots? Le 17 mai 2023 à 21:10, jantje ***@***.***> a écrit : Polluting my source tree with unnecessary sources, which will raise questions and open an unnecessary tab in front of the ArduinoIDE users (i.e. the very people I cannot expect to understand the intricacies of Eclise/Sloeber vs. Arduino); Unless you are talking about other people working on your system or you giving demo's I do not see a problem. If you share using version control there is no need to pollute other peoples folders. Sloeber marks sloeber.ino.cpp as derived so when using eclipse git it is ignored (I don't know how this works) But adding sloeber.ino.cpp to the .ignore works just as well. If you use the folders directly you will also need to add the build folders to the .ignore file. Library and core folders are linked at the eclipse level so are not visible to git. Mmmh, if I’m understanding this right, this (fairly hard to guess) feature, is for importing existing projects with an [projectname].ino file in eclipse the project folder. Which is definitely not the case when working with an Arduino Sketchbook. I think we are cross talking. A call would be easier Thanks again for your dedication and reactivity, It seems to me that your use case it what I build Sloeber for. It is a steep learning curve so I know some help is welcome. — Reply to this email directly, view it on GitHub <#1566 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNAEZBAO5QGEI3UFUE5IWTXGUPAXANCNFSM6AAAAAAYBH6QTM>. You are receiving this because you authored the thread.

[jantje]

If that is Brussels time that is fine for me.

[baudhuina]

It is Brussels time indeed. Pick the most convient timeslot for you! Le 18 mai 2023 à 00:19, jantje ***@***.***> a écrit : If that is Brussels time that is fine for me. — Reply to this email directly, view it on GitHub <#1566 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGNAEZF4UZXFVKTGISPVXJDXGVFGVANCNFSM6AAAAAAYBH6QTM>. You are receiving this because you authored the thread.

[jantje]

Make it sunday.
Send me an invite with your preferred conf tool at [email protected]

[jonbarril]

A subject near and dear to my heart. I see others are trying to combine multiple projects.We were going to do one a year ago about this issue but I got too busy and have been out of town a lot. Did you ever have a conference call with baudhuina? What was the outcome?

BTW: I am having a devil of a time keeping the serial port alive to the serial monitor. File upload is fine, but something is not releasing the port to reconnect the serial monitor after an arduino crash or after disconnect/reconnect the USB port. The only thing that works is to restart eclipse -- ugh

[baudhuina]

We did have the conf call, indeed.
Very interesting to better understand the use cases which guided the development of Sloeber, and learn about possibilities of Sloeber or CDT or Eclipse I didn't know about. Jan's expertise and pedagogical skills are impressive, and it was my priviledge to benefit from it so extensively.
My personal conclusions:

• The workspace is the right Eclipse concept to associate with a repo with software for multiple nodes or multiple binaries in general.
• One Eclipse project per binary with that workspace offers the flexibiity I need to support various hardware configurations without duplicating anything.
• Performing the final build with Arduino is currently still required because the "dot a linkage" of libraries is currently not supported by Sloeber, resulting in possibly very significantly larger binaries (but the is about to change with next version Jan is working on). Not a real issue for me, since preserving compatibility with the Arduino build is a requirement anyway.
• Installing the various Eclipse projects, with the required linked resource to the sketch-specific files/folder could be made easier with some changes in the Project Wizard. Nevertheless, even without them, it is a limited number of configuration steps and can be managed manually.
• Part of my issues are related to my wish NOT to include the eclipse/sloeber project directories in the source repository. Since it is a significant constraint, the need for that was questioned, but I'm still not clear about the possibility to share project folders among developers working in different hardware and software environments. In my experience, it cannot be done without extreme discipline and homogenous HW and SW environment, but I could still be missing something there.

[jonbarril]

Thanks for the detailed response. After a quick read of this thread I thought it was closer to my original one #1506, about linking multiple dependent and nested projects when building projects containing executable ".ino" files. I wasn't concerned about supporting multiple binaries, but perhaps better support for linking dependent nested projects might help.
--jon