multi-level subdirs under dlls/

[Andreas Mohr]

Hi,

On Thu, Dec 11, 2003 at 01:17:08AM -0500, Dimitrie O. Paun wrote:
> Hi folks,
> 
> I know people are concerned right now with more important
> matters, but given that (1) we're cleaning up the tree, and
> (2) we're getting close to 0.9, I figured it maybe time to
> bring this up. Namely,  under dlls/ we have by and large a
> flat structure, with the exception of a few 'special' cases
> (there's always have to be special cases :/). I find this
> rather upsetting, for the following reasons:
>   -- the organization is confusing since it implies some
>      sort of dependency that's not there (they are all .dlls)
>   -- it makes grepping so much more difficult. Instead of the
>      simple:
> 	grep BLAH dlls/*/*.[ch]
>      we need to resort to find, etc.
>   -- it makes scripts in general needlessly complicated
>   -- it hides those parts in the depth of tree
>   -- it is inconsistent with the rest of our DLLs
> 
> Now, I know that this is mainly historical, but why not fix it?
> Yeah, we're going to loose a bit of CVS history, but not quite,
> because the move can mark that so in the log. So we're only
> making 'cvs log' on a few files a bit more complicated, but we're
> simplifying every day operation by so much. I think it's a clear
> win. Here is the list of the offending DLLs:
> 
> ddraw/d3ddevice
> ddraw/dclipper
> ddraw/ddraw
> ddraw/direct3d
> ddraw/dpalette
> ddraw/dsurface
> dinput/joystick
> dinput/keyboard
> dinput/mouse
> gdi/enhmfdrv
> gdi/mfdrv
> msacm/imaadp32
> msacm/msg711
> msacm/msadp32
> msacm/winemp3
> msvideo/msrle32
> user/dde
> wineps/data
> winmm/joystick
> winmm/mcianim
> winmm/mciavi
> winmm/mcicda
> winmm/mciseq
> winmm/mciwave
> winmm/midimap
> winmm/wavemap
> winmm/wineoss
> winmm/winearts
> winmm/winealsa
> winmm/winenas
> winmm/wineaudioio
> winmm/winejack

I'm a bit astonished that you're coming up with that.
I think there's not too much a reason to change this layout:
a) stuff that is very close to each other should be grouped together IMHO
b) rather than wasting time by having to grep through the whole tree,
   you just change into winmm and do a find on all *relevant* files for sound
   support 
c) you don't really want to have all codec files in the main dlls/ directory,
now do you? That could soon grow very messy.

I'm sure there are some other objections, but these are the ones I can come up
with right now.

Having a flat structure has several advantages (in the maintenance area),
but some things do belong together, which has several opposing advantages.

dinput's joystick, keyboard and mouse support could probably be flattened,
right.

Greetings,

Andreas Mohr

-- 
Open Source Software: because smart people know to prefer a multitude of
Support Options to a Single Point of Failure commonly used software represents.
(who's left to sue given your average all-denying End User License Agreements,
or who to ask for support if a vendor or product decided to silently die away?)