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 Fri, 28 Aug 2015 00:07:54 GMT
Sorry Bill.

For the rest, here it is where it should have been sent in the first place.

On 8/27/2015 7:54 AM, William A Rowe Jr wrote:
> On Aug 27, 2015 3:47 AM, "Gregg Smith"<gls@gknw.net>  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.
>
> If we tweak things appropriately, windows or unix Makefiles should be
> emitted for each component of apr-2.
>
> But cmake will equally spit out dsp, sln, eclipse, codewarrior or whatever
> it now is on osx.  I see that as the big win, get more people viewing apr
> from within their personal coding environment.
>
> That's why I want us to extend cmake to do the unix build as well.
>
>> 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.
>
> We can adjust this, yes.
>
>> Let's not remove them and just act like they're not there.
> As I'm suggesting, we won't.  I would like to see us continue to push
> convenience Makefiles for windows without requiring the user to obtain
> cmake, just as we don't require them to obtain autoconf or libtool.

This is fine. I personally do not find them more convenient. They're a 
bear when debugging a single piece of a multi project build. They do 
make a good "when all else fails" option!

> But for those who want MS studio ver X files, or eclipse or whatever
> workspace they like to live in, we can make that easy for them if they
> acquire cmake, first.

This certainly is it's best sell, but it seems both I and Steffen can 
get along with the dsp/dsw. We've been doing it for what now, decade?

> We would generate any convenience makefile not from dsp, a now obsolete
> file format, but from cmake.
> Does that approach satisfy your concerns

No, but I've never stood in CMake's way and I'm not about to start now. 
I just don't get the "this way or the highway" this is sounding like.
Cmake makes a copy of the source and ignores these files creating it's 
own. So seriously, what's the big deal keeping the old school as well?





Mime
View raw message