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"<[email protected]> wrote:
On 8/26/2015 9:56 PM, William A Rowe Jr wrote:
On Aug 26, 2015 11:41 PM, "Branko Čibej"<[email protected]> 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?
