|Re: [AD] Addons directory cleanup|
[ Thread Index |
| More lists.liballeg.org/allegro-developers 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
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:
>> 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:
>> 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?
>> 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:
>> 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.
> 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ń