Question for me is: what is the issue with dsw/dsp ?
Dropping dsw/dsp is not the way to go, for years (VC8-VC14) I use dsw/dsp
GUI to build httpd/apr for Apachelounge.
Dropping dsw/dsp disconnects us from using the (very handy and productive)
GUI and GUI-tools (like edit code, debugging, PGO, tracing, easy handling
properties etc. etc.). We really miss some by dropping.
The dsp is not obsolete ! MS supports dsw/dsp (convert to vcxroj), we
should use this “native” way.
With VC10 converting was a little pain, but now with e.g VC14 no issues,
runs out of the box with httpd/apr.
I am a user, as most of the Windows community, who build http/apr with the
GUI.
Cmake is an extra dependency, which also should be actively! maintained.
When I look at other cmake projects, can be a source of pain and hardly
maintained for the (new) versions of cmake, and has limitations (even apr,
see apr cmake readme). And I see some are not maintaining it anymore and
cmake is broken. like Curl which I tried this year. Maintaining .dsw/.dsp
files is for more easier then cmake.
Bill wrote: ...cmake will equally spit out dsp..
As far I know CMake is not designed to generate .dsw/.dsp files. The
CMakeLists.txt files controls the project.
Why can't we have both? cmake and dsw/dsp.
btw. We have already in httpd Apache-apr2.dsw
Steffen
From: William A Rowe Jr
Sent: Thursday, August 27, 2015 4:54 PM
Newsgroups: gmane.comp.apache.apr.devel
To: Gregg Smith
Cc: APR Developer List
Subject: Re: Time for APR 2.0?
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?
