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