Re: [AD] Addons directory cleanup

[ Thread Index | Date Index | More Archives ]

I thought # include "wav.c" will get a proper image of what may just
happen. My project include various middle-ware libraries and I cannot
promise none is going to include file named exactly like one in
add-ons directory.

I can modify both mentioned branches. About modifying them before or
after release I will relay on your opinion, since I do not have much
experience in release process (and it's implications).

Was there any release from 5.1 branch? I do not remember.

Were iio and kdm_audio leaved on repository by purpose or by accident?

On 23 October 2011 02:44, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On Sun, 23 Oct 2011 00:34:32 +0200, Michał Cichoń <michcic@xxxxxxxxxxxxxxx> 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
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@xxxxxxxxxx Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> --

thedmd, Michał Cichoń
Artifex Mundi

Mail converted by MHonArc 2.6.19+