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: [email protected] > 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: [email protected] >> 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 >> >
