On Aug 27, 2015 3:47 AM, "Gregg Smith" <g...@gknw.net> wrote: > > On 8/26/2015 9:56 PM, William A Rowe Jr wrote: >> >> On Aug 26, 2015 11:41 PM, "Branko Čibej"<br...@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. 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. We would generate any convenience makefile not from dsp, a now obsolete file format, but from cmake. Does that approach satisfy your concerns?
