I hope we do not lose then the GUI or GUI tools mandatory functions, I have
my doubts (see my first post in this thread).
I second on Gregg's proposal: Let's not remove them and just act like
they're not there. I want to say just keep them till cmake is proven.
The few dsw/dsp files are easy to maintain and are a flexible way to do what
we want with all VC versions (VC6 up to VC14).
@Gregg : what about the .make files ?
I look forward to see how cmake is implemented. Waiting for a tag, so I
can give eventually additional requirements.
For me, dropping dsw/dsp discussion can be closed.
Steffen
-----Original Message-----
From: Branko Čibej
Sent: Thursday, August 27, 2015 8:03 PM Newsgroups:
gmane.comp.apache.apr.devel
To: dev@apr.apache.org
Subject: Re: Time for APR 2.0?
On 27.08.2015 19:59, Steffen wrote:
As long as we not loose any mandatory GUI and GUI tools
functionality, then no problem
That's why I proposed completely replacing the dsw/dsp files with cmake.
There isn't actually a supported version of Visual Studio that could be
used to maintain those files; current versions can convert them to
sln/vcxproj, but as far as I know can't save back to the original format.
@Brane I mail you off list (I do not want to clutter the list) about
your arguments concerning the 3 issues you have with dsw/dsp.
The purpose of this list is for having these discussions. If you have
comments, please post them here.
-- Brane
-----Original Message----- From: Branko Čibej
Sent: Thursday, August 27, 2015 7:19 PM Newsgroups:
gmane.comp.apache.apr.devel
To: dev@apr.apache.org
Subject: Re: Time for APR 2.0?
On 27.08.2015 19:12, Steffen wrote:
I said: As far I know... CMake is not designed to generate ... But
it can.
Further as far I know :), but I can be wrong.
CMake is not designed to generate dsw/dsp files that can be edited from
Visual Studio. It should not be used to initialize a project and then
dropped. The CMakeLists.txt files control the project. Any changes
that
are made to the .dsp files will not be reflected in the MakeLists.txt
files.
The .dsp files should not be removed or modified by anything but CMake.
You came up with the dropping idea; Question for me is: what is the
issue
with dsw/dsp ?
Quit a few in fact.
They don't work with any current version of Visual Studio; they have to
be converted to .sln/vcxproj. So your argument about "any changes to
.dsp" not being reflected in CMakeLists.txt is moot.
There should only be one source for build system configuration. If we're
going to use cmake, that'll be CMakeLists.txt and a bunch of other cmake
files. If that's done right, there's no reason to lug around obsolete
project files that are likely to be out of sync with the canonical build
system anyway.
The same argument goes for the "convenience" Windows makefiles ... they
don't work most of the time. If we want to include them in a release,
they should be generated by cmake at release time, not part of the
repository.
-- Brane
-----Original Message----- From: Branko Čibej
Sent: Thursday, August 27, 2015 6:59 PM Newsgroups:
gmane.comp.apache.apr.devel
To: dev@apr.apache.org
Subject: Re: Time for APR 2.0?
On 27.08.2015 18:49, Steffen wrote:
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.
Please read the whole thread. cmake can generate dsp and vc(x)proj files
for all versions of Visual Studio.
-- Brane
