Michael Widenius wrote:
>>>>>> "Tor" == Tor Didriksen <Tor.Didriksen@stripped> writes:
>>> MySQL was design with the idea that you in most cases only have to
>>> include one (but in practice a few) include files in each source file.
> Tor> #include mysql_priv which pulls in just about everything, yes.
> Tor> This practice makes it impossible to do unit testing.
> There is nothing that stops you from testing one unit, just because
> you include a more include files than you need.
> Why would it do that ?
> After all, when you include 'stdio.h', you are including a lot of
> files and references to functions that you are not using and it
> shouldn't stop you from doing an unit test.
stdio.h is not part of a circular dependency and it is carefully designed to
allow precisely what you suggest. The mysql_priv.h file is not designed for that
purpose, which makes it very hard to use.
As a comparison, note that the standard holds several include files: stdio.h,
stdlib.h, stddef.h, strings.h, etc. each with a specific purpose and with a
clear design. In contrast, mysql_priv.h acts as a single include file for all
of them, with no separation at all and with no design at all. It contains code
to define bitmaps, arrays, list, a collection of handy macros that only seems to
be used at one or a few places in the code, various global variables, locale
structures and functions, to mention a few.
> Actually, you are at risk if having irrelevant unit tests if you don't
> do things the same way for the unit test, as you do in the code your
> are using it with. See below...
> Tor> 'include or declare what you use' is a very simple rule,
> Tor> and makes the code much more maintainable and testable.
> I disagree strongly with this.
> Having a 'master include' that everyone needs to include
> makes life simpler and is less risky for bugs:
> - You don't have to have a huge, impossible to maintain include list
> in each .c file.
That is a very subjective statement.
> - You don't have to add new include files just because you add a call
> to another function.
I don't see that as a good thing, my view is that we should encourage a style
where you include the interface file (functions are part of an interface) when
using the interface.
> - People forget to remove include files when changing/moving code.
> The include files in the beginning of the file will over time
> include much 'noise'.
In contrast, including mysql_priv.h is guaranteed to include a lot of 'noise'
because files are not using everything in mysql_priv.h, just a subset of what is
there, which makes this is an argument *against* mysql_priv.h because that file
will accumulate noise from all files.
> - Having different include files makes compilation notable slower on
> all compilers/systems that supports precompiled headers.
> (like windows).
As I already mentioned, I don't think the coding style should optimize to
minimize the includes: it should promote clean interfaces and clear *explicit*
> - For example, Microsoft recommends one to have master include files,
> just because of the above (at least they did when I last worked with
> - You can not be sure that the 'unit test' you are using will
> will not be tested in the right environments compared to the
> original programs as some of the include files you don't include
> may change the environment (for examples with defines or #ifdefs).
> Having one or a many include files in each .c file is a matter of
> taste and I personally prefer to have one major include file for each
> From the practice I have with MySQL, I can say that it the current
> style has made things much easier and have allowed us to avoid a lot
> of bugs and time.
> It's true that this is at the expense that in the
> few cases we have to add a new include file, one has to think a bit
> where to include them but compared to the overall coding process
> this time is neglectable.
I disagree. I have spent plenty of hours on "pointless" coding (figuring out
what to include, *how* to include, what to link with, etc.) that I have not had
to do in other projects, commercial as well as open source.
Senior Software Engineer
Database Technology Group