I've seen this kind of thing before -- it must be on the forums somewhere! There is a way to make a "verbose" setting, in the main preferences file I think, that helps in some cases.
Thanks - I had actually found build.verbose and upload.verbose in the preferences file and set them true. It made no difference. But in response to your post I discovered that, if you edit the file while the development environment is running, it overwrites it with the old values when you quit (which is actually understandable). Lesson: quit, then edit.
Now I get a list of what it's doing, which is better:
But the bar still goes red at the end indicating that something's wrong, but no indication of what.
So I ran the last command in a terminal window, which - inter alia - gave me
In file included from /tmp/build23199.tmp/Temporary_6723_3259.cpp:18:
/tmp/build23199.tmp/cartesian_dda.h:163:2: error: #endif without #if
which allowed me to fix the problem. But - despite setting all verbose values true - I still didn't get that rather important message in the development environment.
Does anyone know why this happens? Is it because the error occurs in a library (and the library build process is separate from the sketch build process)? Or is there a race condition similar to the problems with showing the size of a compiled sketch?
The way that the IDE captures the output from external processes is a bit problematic. I took a look at it briefly and did not see a trivial fix. If I do look at it again I might refactor it. A lot.
The problem with fixing these sorts of problems is that the easiest way to make the problem go away is to put the debugger on it, or add some logging! This is what the verbose setting sometimes magically solves things.
So it requires someone who really want to bite into it, and who can reproduce it. I'm not quite the former (yet) even if I'm the latter. Another problem is that I mostly use make at the command line to make sketches now, so I have little personal incentive to improve the IDE. Yes, a terrible excuse, but what can you do?
But, I will try to take a look at this one this week-end. Like I said, I think there will be a fair amount of refactoring to do, so it may take awhile to get right.
Any help would be appreciated. I already committed your patch for Sizer.java. Even if you don't have time to find a correct fix, any diagnostics would be useful.