Specially-named header file for providing #defines to the core and library on a per-sketch basis.

[GoogleCodeExporter]

(this "defect" is partially to try out the google defect tracking system
If a sketch folder includes a file "wiring_options.h", it will be added as
a "forced include" during the compilation of the wiring library files (ie
"-include <path>/wiring_include.h")  This would allow a sketch to override
default values of #defines in the wiring files (assuming that the files are
converted to allow such overrides, which is a separate issue.)  The most
obvious example would be the RX_BUFFER_SIZE used in the serial libraries.

(This patch is from the trunk circa Arduino14.  It may or may not still apply.)

Original issue reported on code.google.com by wes...@gmail.com on 5 Jun 2009 at 8:12

Attachments:

• forceinclude.diff

[GoogleCodeExporter]

I think this is only possible in the forthcoming Arduino 0017, as currently the 
libraries are pre-built (when a 
board is selected).  This is changing so that the the libraries, core, and 
sketch will all be compiled together, at 
which point the -include could be applied to all of the source files.  I'm 
still not convinced this is needed, but it's 
starting to seem more useful.  What about just something like "config.h" or 
"options.h" instead of 
"wiring_options.h"?  

Original comment by dmel...@gmail.com on 5 Jun 2009 at 8:23

[GoogleCodeExporter]

My preferred approach to this issue would be to check for the
existence of a specially-named header file in the sketch (e.g.
options.h or config.h) and, if it exists, include it (on the avr-gcc /
avr-g++ command line) while compiling the core and libraries for the
sketch.  This header file could then include any #define's needed to
override their configuration.  It has the advantage of being a
standard header file, something that the IDE already supports the
editing of.  On the other hand, it wouldn't let you change the
arguments passed to the compiler.

I'm still not, however, quite convinced that something like this is
useful enough to include.  In particular, it exposes portions of the
internal implementation of the core and libraries in a way that people
will start to rely on.  If we changed the name of some internal
constant, it would break the config.h files that used it.  Also, we
don't know how much people would start trying to customize or hack the
core and libraries through the use/abuse of macros.  We'd potentially
be encouraging the proliferation of sketches that were very much
dependent on the internals of the core and libraries, and therefore
unlikely to be portable across updates to the software.  I'm not sure
it's worth it just to let people change the size of the serial
buffers.

Original comment by dmel...@gmail.com on 10 Mar 2011 at 11:50

[GoogleCodeExporter]

Issue 339 has been merged into this issue.

Original comment by dmel...@gmail.com on 15 Aug 2011 at 8:43

[GoogleCodeExporter]

Another use case for this would be compile-time allocation of timers to various 
functions (e.g. tone() vs. Servo).

Original comment by dmel...@gmail.com on 16 Aug 2011 at 9:02

• Changed title: Specially-named header file for providing #defines to the core and library on a per-sketch basis.

[GoogleCodeExporter]

Issue 783 has been merged into this issue.

Original comment by dmel...@gmail.com on 9 Jan 2012 at 12:45

[GoogleCodeExporter]

Whether including a config.h for the Arduino core parts is useful is debatable. 
However there is currently no way to change the compilation of "libraries" I 
download from elsewhere or make myself, so it's difficult to write generic code 
that is reusable. Making everything be evaluated at run-time is not possible 
(using if statements) is not appropriate with microcontrollers and a few kbyte 
of code space.

This problem needs a solution. Having issues open for years doesn't help.

Original comment by gooc...@top.geek.nz on 9 Jan 2012 at 8:56