Re: [Ekiga-devel-list] Cleaning our config.h's situation

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

On 18/10/10 17:23, Julien Puydt wrote:
> Hi,

Hi Julien,

> Problems :
> (1) we don't include config.h everywhere, which limits its usefulness;

No!  It is boring to have it included everywhere, just in case.  It 
should not be included in each file, but only on files which need it. 
Also, when you modify or create a file which needs it, then you can 
include it.

> (2) we don't seem to have a 100% clear policy of where we should include
> it from : it is for example included in both ekiga.h and ekiga.cpp,
> while other places include it from their .cpp directly;

The good practice as far as I know is to have headers included in .c, 
not in .h, which leads to clean files.  In exceptional cases where the 
.h needs it (is there one in ekiga?), it can be included in the .h.

> (3) the configure.ac does things about gtk-debug which should probably
> belong to the "DEBUG support" section ; and it does things poorly by
> putting directly things with -D in the flags -- it probably should do
> some AC_DEFINE magic so it appears in config.h (which brings us to point
> (1)).

It is too minor to deserve a modification/commit, especially that 
gtk-debug is to find out if ekiga is ready for gnome 3 (it would have 
been better to name it gtk-readiness for ex.), while "DEBUG support" 
part in configure.ac is for debugging (as in gdb debugging).

> Solutions :
> (1) remove and add #include "config.h" according to point (2) below ;
> (2) fix a policy ; I propose to choose from two of them :
> (i) include in all header files, as first non-comment and non-empty line ;
> (ii) include in all source files, as first non-comment and non-empty line.

So I agree with moving config.h in order to be the first header 
included, cf. 
http://www.gnu.org/software/autoconf/manual/html_node/Configuration-Headers.html#Configuration-Headers

And I think it is bad to add it to each file only to be "homogeneous". 
Better to be simple (use it when needed) than homogeneous and "complex".

> (3) modify the order and use AC_DEFINE instead of flags voodoo in
> configure.ac.
>
> I would push for policy (i) for two reasons :
> - if for some reason we would like config.h to have an effect on header
> files, then it should appear there ;
> - sometimes the header is the implementation!
>
> Comments welcome, help even more so!