apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: Time for APR 2.0?
Date Thu, 27 Aug 2015 18:03:35 GMT
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
>>
>


Mime
View raw message