On Tue, 2009-11-24 at 16:54 -0800, David Brownell wrote:
> On Tuesday 24 November 2009, [email protected] wrote:
> > It is an error to require other headers to be included first, so declare
> > what we can (struct declarations) and include the rest (Jim types).
> 
> This one seemed out of step with the rest of these 80+ patches.
> 
> Any particular reason why that should be an "error"?
> 

Well.... I suppose that might be dropped, but that patch came out of
writing the testee target driver that comes next.  That code is
ridiculously minimal, in that it doesn't even include target.h yet.  If
that got included in the C file first, it might solve the problems that
this patch addressed.

That said, it feels like very bad form to omit forward declarations or
bare minimum #include directives that prevent a header from compiling by
itself.  If you feel that this header should always be #included _after_
target.h, then I'll rewrite the patch for that, but I hate the idea.
Personally, I think this is another style point that has no objective
winner, so what _exactly_ do you want in regards to headers?  And don't
tell me, write it up for the Style Guide. :)

Now, I know you did some cleaning in this particular area, which my
recent purge of the struct typedefs allowed.  Prior to that effort,
forward declarations like those I added in this patch weren't even
possible, so that allows 90% of the stuff to be decoupled and solves
most of the problems.  It's still much better than being forced to
include all of the headers that included the type definitions, though
Jim remains a notable exception to that rule.

In summary, I think headers that don't compile by themselves (except for
the system headers provided through config.h) are broken, but there is
much work to be done with the cleaning up the headers further in
general.  I'll get back to that again at some point, since removing the
struct typedefs has opened new opportunities for refactoring.


--Z

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to