Re: fix for bug #47381, how to order #includes

[Rik]

On 03/25/2016 03:30 PM, Mike Miller wrote:
> Rik, all,
>
> The fix [1] for bug #47381 [2] accidentally breaks building Octave
> without gl2ps [3]. The header file associated with gl2ps-print.cc,
> gl2ps-print.h, needs to be #included outside of the HAVE_GL2PS_H
> condition.
>
> This is easy to restore, but any ideas how to avoid accidentally
> rearranging things like this in the future? I'd be tempted to clean up
> includes in the same way and make the same mistake. The graphics classes
> are particularly complicated. Should we comment when #includes are
> grouped for particular reasons like this? Should we use additional #if
> blocks to separate conditional includes from unconditional includes, and
> conditional code from unconditional code?
>
> [1]: http://hg.savannah.gnu.org/hgweb/octave/rev/ab8760b1245d
> [2]: https://savannah.gnu.org/bugs/?47381
> [3]: https://hydra.nixos.org/build/33552213
>
Apparently "no good deed goes unpunished".  I was adding a header include
and thought I'd take the extra minute to clean up and rationalize the other
includes--only to introduce a bug.

I suppose comments are the first defense.  Another possibility is to
actually spend time to go through the list of #includes for the various C++
files and rationalize them: remove the unnecessary ones, re-order them into
alphabetical order if no better plan exists, etc.  If that were done then I
could trust that the grouping that kept gl2ps-print.h outside the #ifdef
block was made for a reason.  As it is, I usually assume that there is no
rhyme or reason as to why the includes are there.

--Rik