Re: [AD] Addons directory cleanup

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Sun, 23 Oct 2011 00:34:32 +0200, Michał Cichoń <michcic@xxxxxxxxxx> wrote:
> Hello,
> 
> I have two propositions with regard to add-on directory:
>  - remove unused directories: iio, kcm_audio

I didn't know they were still there.

>  - reflect main directory structure in add-on directories
> 
> While first one does not need the comment, second should be explained
> a little bit.
> Maybe by example. Let's take a look at acodec add-on directory tree:
> 
> allegro5\
> allegro5\internal\
> allegro5\internal\aintern_acodec_cfg.h.cmake
> allegro5\allegro_acodec.h
> CMakeLists.txt
> acodec.h
> wav.c
> ogg.c
> modaudio.c
> flac.c
> acodec.c
> 
> Now, while preparing monolith build and using Allegro inside other
> project I hit a problem of polluted include list. I can actually write
> # include "wav.c" and whole wav.c source will be included (!).

I don't get it.  Why is Allegro inside another project, and
why are you writing #include "wav.c" in the first place?

> To
> prevent such situation in the future I propose to reflect Allegro
> directory tree inside add-ons:
> 
> include\ - public headers
> src\ - source code
> misc\ - support/additional files which are not a part of the add-on
> directly (nshader.cpp for example in primitive add-on)
> 
> So, complete acodec library with new layout will look like that:
> 
> include\allegro5\
> include\allegro5\internal\
> include\allegro5\internal\aintern_acodec_cfg.h.cmake
> include\allegro5\allegro_acodec.h
> src\acodec.h
> src\wav.c
> src\ogg.c
> src\modaudio.c
> src\flac.c
> src\acodec.c
> CMakeLists.txt
> 
> This way I could just point to 'include' directory, which is not
> polluted with C files. cmake files are harmless.

Seems like you only really need to introduce the include directory, and
nothing else.

> I'm interested in your approval. Before I do such modification.

I'm fine with a bit of rearrangement, but it will need to be done in
both the 5.0 and 5.1 branches so that cherry-picking changes from one to
the other will work smoothly.  It might be best to release 5.0.5 and
5.1.0 in quick succession, then rearrange both.

Peter




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/