apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Smith <...@gknw.net>
Subject Re: Time for APR 2.0?
Date Thu, 27 Aug 2015 09:14:05 GMT
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.




Mime
View raw message