Fastled: Pragma Messages During Compile Time

Created on 28 Oct 2016  路  5Comments  路  Source: FastLED/FastLED

Please remove these or provide an easy way to disable them. It's really distracting from actual compile errors.

screenshot 2016-10-28 16 27 59

Most helpful comment

This is going straight into all my projects. I'm not a fan of the pragma message. It is the ugly stain on one of the nicest libraries I've ever used.

  • It violates best practice for unix commands (if something went successfully, no output is needed; granted this is not a unix command)
  • It builds fatigue (oh, whooops, there _was_ actually a warning that scrolled by? oh well, might have been the pragma mesage, nevermind)
  • It is visual noise for thousands (judging from the github star count) if not tens of thousands of programmers. This makes work harder, when there actually _are_ compile errors (illustrative example in the original post). They then have just another set of lines to inspect in their compiler output.
  • It associates errors with FastLED itself, even if it's not at fault. FastLED is quite stable in my experience. There hasn't been a single error with it from my point of view. At the same time, I had to fix something on the order of a hundred errors with my own code. Every single time, I'm first greeted by a friendly FastLED message somewhere in the mess. At some point you start to associate the two. Even if it's not to blame.

Messages like this only ever belong in some kind of opt-in debug mode.

Thanks for at least letting us opt-out.

All 5 comments

Pragma messages should not be getting marked as warnings or errors - that's a bug you should file with the IDE. In the meantime, you can disable them by including #define FASTLED_INTERNAL before #include <FastLED.h>.

I will not be removing them because the information is useful to me in build logs when people submit bugs (the number of times I"ve been able to quickly point out to someone that they don't have the version of the library that they think they have makes it worth keeping in).

I'll stick in #define FASTLED_INTERNAL thanks for library!

This is going straight into all my projects. I'm not a fan of the pragma message. It is the ugly stain on one of the nicest libraries I've ever used.

  • It violates best practice for unix commands (if something went successfully, no output is needed; granted this is not a unix command)
  • It builds fatigue (oh, whooops, there _was_ actually a warning that scrolled by? oh well, might have been the pragma mesage, nevermind)
  • It is visual noise for thousands (judging from the github star count) if not tens of thousands of programmers. This makes work harder, when there actually _are_ compile errors (illustrative example in the original post). They then have just another set of lines to inspect in their compiler output.
  • It associates errors with FastLED itself, even if it's not at fault. FastLED is quite stable in my experience. There hasn't been a single error with it from my point of view. At the same time, I had to fix something on the order of a hundred errors with my own code. Every single time, I'm first greeted by a friendly FastLED message somewhere in the mess. At some point you start to associate the two. Even if it's not to blame.

Messages like this only ever belong in some kind of opt-in debug mode.

Thanks for at least letting us opt-out.

As @ccoenen wrote, I also find pragma messages inappropriate, and should be suppressed by default.
If they are meant to make easier to debug users problem, then maybe it could be default header FastLED.h which has suppressed messages and DebugFastLED.h which enables messages. Then you can ask users to include it. Or #define FASTLED_ENABLE_DEBUG_MESSAGES...

I also agree on the majority of users regarding pragma messages, especially ccoenens writeup of very good reasons to why it should not be there.

If it is helpful for some but distracting for most there should be an opt-in instead of an opt-out, as d21d3q mentioned.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Polishfuze picture Polishfuze  路  4Comments

altimmons picture altimmons  路  3Comments

renarsvilnis picture renarsvilnis  路  3Comments

CRCinAU picture CRCinAU  路  8Comments

ccoenen picture ccoenen  路  6Comments