[MPlayer-cvslog] CVS: main/libao2 afmt.c, 1.7, 1.8 afmt.h, 1.8, 1.9 ao_alsa.c, 1.9, 1.10 ao_alsa5.c, 1.19, 1.20 ao_arts.c, 1.8, 1.9 ao_dsound.c, 1.3, 1.4 ao_dxr2.c, 1.7, 1.8 ao_esd.c, 1.7, 1.8 ao_jack.c, 1.4, 1.5 ao_macosx.c, 1.5, 1.6 ao_mpegpes.c, 1.20, 1.21 ao_nas.c, 1.15, 1.16 ao_oss.c, 1.44, 1.45 ao_pcm.c, 1.21, 1.22 ao_plugin.c, 1.25, 1.26 ao_polyp.c, 1.1, 1.2 ao_sdl.c, 1.37, 1.38 ao_sgi.c, 1.7, 1.8 ao_sun.c, 1.29, 1.30 ao_win32.c, 1.16, 1.17 audio_out.c, 1.44, 1.45

[D Richard Felker III]

On Tue, Dec 07, 2004 at 03:48:18PM +0100, Aurelien Jacobs wrote:
> On Tue, 7 Dec 2004 12:20:55 +0100
> Felix Buenemann <atmosfear at users.sourceforge.net> wrote:
> 
> > On Tuesday 07 December 2004 10:05, Reimar Döffinger wrote:
> > > Hi,
> > >
> > > > Modified Files:
> > > >  afmt.c afmt.h ao_alsa.c ao_alsa5.c ao_arts.c ao_dsound.c
> > > >  ao_dxr2.c ao_esd.c ao_jack.c ao_macosx.c ao_mpegpes.c ao_nas.c
> > > >  ao_oss.c ao_pcm.c ao_plugin.c ao_polyp.c ao_sdl.c ao_sgi.c
> > > >  ao_sun.c ao_win32.c audio_out.c
> > > > Log Message:
> > > > Make include paths consistent.
> > >
> > > So you didn't yet remove the double config.h includes.
> > > But there is another thing I saw: nearly all modules that include
> > > mp_msg.h include help_msg.h as well. And even those that don't
> > > should do it IMHO as it makes translating easier. So my suggestions
> > > is: make mp_msg.h include help_msg.h, and remove all (except a few
> > > in the Gui) includes of help_msg.h. What do you think about that?
> > One common rule of thumb by arpi says, never include include-files
> > from within include files...
> 
> Huh ! I really wonder why ? I guess there is a good reason for this
> but I can't see one.
> 
> For example with a.h using a type defined in b.h, this mean that
> every .c files including a.h also need to include b.h. And this
> mean that developpers who include a.h somewhere need to know that
> he have to include b.h. This also mean that if someone add a
> declaration in a.h using a type in c.h, all the .c files using
> a.h will have to be modified to also include c.h.
> 
> I really can't see the whole purpose of all this redondancy and
> complexity ?

otherwise you'll often have the same header included many times, and
the compiler has to parse the whole damn thing each time...

rich