Skip to content
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

automatic inclusion of sketch_globals.h for sketch.ino and libraries #1524

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

d-a-v
Copy link
Contributor

@d-a-v d-a-v commented Oct 20, 2021

  • The PR has no duplicates (please search among the Pull Requests
    before creating one)
  • The PR follows
    our contributing guidelines
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)
  • No breaking change
  • What kind of change does this PR introduce?

User is given the ability to add local overriding for cpp-defines used by sketch and libraries.
This is done through a new and optional user file editable from Arduino-GUI and which must stand beside someSketch.ino under the name someSketch_globals.h.

When it exists, this file is automatically included first in all compilation units (.ino, .cpp) through the compiler's -include file command line option.

This is yet another proposal for #846 and arduino/Arduino#421, and follows #1117 and #1517.

Features:

  • Libraries can be configured without modification
  • No change required from configurable libraries which support macro overrides.
  • Self contained projects archive embedding library configuration
  • Single C++ header file per project to configure all used libraries
  • Compatible with Arduino 1.8's GUI
  • platform's Core source files do not include the user global header file (edit)

follows #1517 (comment) .

@z0nt
Copy link

z0nt commented Dec 8, 2021

I'd suggest renaming to:

automatic inclusion of sketch_globals.h for sketch.ino and libraries

@d-a-v d-a-v changed the title automatic inclusion of proj_globals.h for proj.ino and libraries automatic inclusion of sketch_globals.h for sketch.ino and libraries Dec 10, 2021
@PaulStoffregen
Copy link
Sponsor

Before merging this, please consider the long term effect on the Arduino ecosystem. Historically, Arduino has rejected this idea. If it's now considered okay, then great.

@d-a-v
Copy link
Contributor Author

d-a-v commented Dec 12, 2021

I can't see any adverse effect for backward compatibility.
If you have one in mind please elaborate.

@z0nt
Copy link

z0nt commented Dec 12, 2021

Having a single sketch_globals.h is probably not very safe. This approach may cause macro name clashing from different libraries. We cannot assume that all libraries use prefixed macro names. I'd suggest to have one config file per library - LibFoo_config.h, LibBar_config.h, etc. When LibFoo is being built only LibFoo_config.h is included (if exists). Let me know what you think.

@d-a-v
Copy link
Contributor Author

d-a-v commented Dec 12, 2021

I think a way for using global defines is really lacking in the Arduino build system for a user point of view, in the same sense where in any other build environment that I know of, there is always a place where one can add some custom #defines, which are enabled in a global manner.

Allowing to use a separate and distinct file per library is an interesting idea, which indeed would avoid name clashing.
However I can't seem to be able to identify a single build environment where one could add external custom set of defines per included library / directory (makefiles and cmakefiles don't do that, eclipse has a global configuration place, platformio too, I have no knowledge for others).
So it appears as just not natural to me.
Also I believe its use would be quite not easy for everyone, because it is not rare that an Arduino library is stored into TheLibrary/src/LibraryHeader1or2.h. Then on what base the NameForALibrary_globals.h should be chosen in a safe and predictible manner ?

Having a single file named after user's sketch appears more simple to me, and sticks to the Arduino simplicity.

About library name clashing, this is indeed an issue.
However if the proposed feature is (ever) adopted in Arduino, library authors would surely accept little and backward compatible changes in their library. Also, as some Arduino libraries are also used in other build environments they are already prepared for this use and probably already have unique sets of defines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself type: enhancement Proposed improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants