septillion:
That will indeed work but doesn't make the code smaller after the debug period.
Well, if that's the goal, then there really is no option other than a #define in a shared .h file, which the OP already said he didn't want. A library cannot "see" #defines referenced only in other compilation units.
Correct. But if it's for debug purposes I don't see much hassle in doing it in a .h... It's not like you need to change it daily... Write code in debug mode and once you are happy, comment out the debug and off you go
Thanks for help, OK I see it ist not possible. In my case it was not only for pure debug action, but to give optional additional information output on the serial console for somebody useing my library (in special a library for WiFi connection with several options). So I thought it would be easyer to activate the output from his source instead to have modify the cpp file. Passing via variable is not meaningfull as it do not save code, as mentioned above.
So the user of my library will have to modify the cpp file.
Put it in the .h, that's considered to be the more editable file of the two (Because it outlines the working of the library, not the implementation as the .cpp does.)
I was at a similar point a while ago. I moved a few constantly reused parts of my home automation projects into libraries (connecting to wifi, mqtt server, maintaining connection, controlling lights over mqtt, that sort of stuff).
I originally also expected to just activate DEBUG in my sketch and get that output from the libs. That does not work, because the include includes the header file, not the cpp file. So a function-like define (like the debug define below) in the header will profit for a prior DEBUG define, but not a cpp file. The cpp file ins compiled in its own contect and only knows about the includes in itself. A header file is therefor included twice: Once in the sketch, where it tells the compiler how the methods from the library look, and once in the cpp file, where the actual methods are that are later linked to the sketch.
I came to the conclusion that I actually mixed up different debug outputs:
There is debug output for the library answering the question "Does my method actually do what I want it to do?" and
debug info for the sketch, which is stuff like the IP address that was assigned to the node, so I can see if my credentials in the sketch are fine and that sort of stuff.
I recommend dealing with 1. with a precompiler debug define in the header of the library. Someone who is interested if the methods work is someone who at least potentially works on the library, so it is fine the library header is changed.
2. is important for every user of the library, as perfect as it may be. Deal with this on compiler level. Other people will be able to supply you with more competent information, but I am pretty sure if you include the debug flag into the constructor and then save it as a constant class member, then the compiler will still be able to optimize any code away that depends on this constant being true. If it is clever enough to detect that a public variable that is set to false at some point will never be touched again, I don't know.
For a the precompiler stuff, I user this header file:
After that, you can user DEBUG_PRINT(x); like Serial.print and don't clutter your code with all these #ifdef's. The broken indentation makes the code really hard to read. If you #define DEBUG before including this header, it will act on this code, since there is no cpp file which gets compiled in it's own context.
