[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

[Reimar Döffinger]

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...

I guess this does not really apply in this case, but I also think now
that the change is not worth the trouble.
So I withdraw my suggestion.

Greetings,
Reimar Döffinger