Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <55DED4DD.4050807@gknw.net>
Date: Thu, 27 Aug 2015 02:14:05 -0700
From: Gregg Smith <gls@gknw.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: Time for APR 2.0?
References: 
 <CAAR2etPnA7YeeGY2FbH8biXzmOUJLBXjSnm8QmHpJ_j-dBf+Ew@mail.gmail.com>
	<55DE941F.20904@apache.org>	<55DE94FE.1030909@apache.org>
 <CACsi2533c4HLc1eyYRZvQMrt5FKA_6PHm-0b87W-3BTwH6eDmA@mail.gmail.com>
 <55DECE11.8030800@gknw.net>
In-Reply-To: <55DECE11.8030800@gknw.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 8/27/2015 1:45 AM, Gregg Smith wrote:
> On 8/26/2015 9:56 PM, William A Rowe Jr wrote:
>> On Aug 26, 2015 11:41 PM, "Branko Čibej"<brane@apache.org>  wrote:
>>> On 27.08.2015 06:37, Branko Čibej wrote:
>>>> On 27.08.2015 05:46, William A. Rowe Jr. wrote:
>>>>> Several years ago, we combined the functionality of apr and apr-util,
>>>>> and that library no longer draws in sub-dependencies until specific
>>>>> components are necessary (dbm providers, dbd providers, crypto
>>>>> providers etc).
>>>>>
>>>>> It seems overtime that we produce a release based on that effort, I'm
>>>>> offering in absence of other volunteers to prepare an -alpha 
>>>>> candidate
>>>>> in mid-September.
>>>>>
>>>>> We don't work on the same clock as downstream distributors, so
>>>>> whatever effort we make in Sept won't see broad distribution until
>>>>> 2016.  But if the httpd, svn and other consumers have successfully
>>>>> integrated with the 2.0 trunk/ development effort, it seems like this
>>>>> is a good time to begin to make that happen.
>>>>>
>>>>> Thoughts/comments/roadblocks/showstoppers?
>>>> Good move.
>>>>
>>>> There are a few long-outstanding patches from the SVN devs that I'd 
>>>> like
>>>> to get into the code first, so mid-September is a good goal.
>>> On that topic, what would it take to take the Windows cmake build off
>>> 'experimental' status for 2.0 and remove the .dsp and .mak files?
>> IMVHO?
>>
>> 1. Purge the dsp/mak files.
>>
>> 2. Promote cmake structure to create valid win or unix or other builds.
>>
>> I am personally very interested in this effort and will jump on some
>> aspects of it this week.
>
> First I must state that I am not against CMake or getting  it off of 
> 'experimental' status, I'm glad we have the option now. I am for 
> promoting it and  for not even mentioning the old school way in 
> whatever readme there is on building.
>
> I am against removing the dsw/dsp however (there are no mak/dep 
> files). It's not a huge load, there's only 24 files counting all the 
> crypto, dbd, dbm and test dsp/dsw/win out of the 631. You barely 
> notice them if you're not looking for them. I would not be against 
> chucking out the dbd_freetds and even the sqlite2 dsp files which is 
> then 23/22.
>
> VC10 is rather hopeless but 11 on seems workable. Renaming the dll and 
> lib projects to -2 will stop the insensate whining about. This should 
> not be a problem in 2.0.
>
> Let's not remove them and just act like they're not there.

And by "insensate whining," I'm speaking of the post VC9 compilers, not 
users.