On Thu, Aug 27, 2015 at 6:53 PM, Noel Butler <[email protected]> wrote: > > That's why I want us to extend cmake to do the unix build as well. > > > > The biggest bitch I here from *nix/bsd system admins everywhere is cmake, > the largest bitch is people know how to use --with-foo --with-bar now > after decades, THEY, the people you expect to use your software, have to > learn it no longer works that way, I know of multinationals change software > because of cmake, I've seen a well known large international issue a policy > that they will remain on old unsupported versions of mysql because they > moved to cmake. > > autoconf et al, might be ol school, but every man, woman, and dog knows > and understands it, and its more than time proven, I've heard that cmake is > an in thing for windows stuff (I dont use any windaz anywhere in our ops), > but have you seen the stats on windows servers V *nix/bsd lately, cmake may > or may not be nicer for devs, but devs rarely manage any large number of > servers outside of their own build vm numbers, so I'd think twice before > changing unless you keep ol school as well. > > I for one, consider it a PITA as well, thats my opinion anyway. > Funny you should mention this. I have no intention of replacing autocruft with cmake, certainly not in 2.0. Unlike .dsp support, the format it is still maintained.
Sort of... I've wasted a day on our lack of understanding of writing autoconf detection and structuring apu-config-1; the internal openssl includes and libpath/libs which were not for the end consumer are bleeding into apu-config and therefore into httpd's ./configure. Of course, there happened to be yet another copy of apr hiding over there, so I'm no longer able to build a complete matrix of httpd revs vs. apr revs vs. openssl revs. Uncool. Sort of again... wasted half a day yesterday looking at the ar cruD that binutils has promoted, Fedora unwisely adopted without first addressing autoconf and libtool - punting the question to the automake folks who sit too far up the chain to be much help. So ac/lt will be with us for a while, but this will be substantial proof that we built a portable and generalized cmake structure for the project. If it flies, and if it emits .vcproj/.dsp/.mak files that are usable, I'll demonstrate this and we can promote it from experimental, striking the .mak/.dsp files from the tree, just as we don't keep a generated ./configure in the vc tree, either. On Thu, Aug 27, 2015 at 6:52 PM, Gregg Smith <[email protected]> wrote: > > > We would generate any convenience makefile not from dsp, a now obsolete > > file format, but from cmake. > > Where the makefiles come from is not really a concern. The dsp/dsw is because of the approach it uses. Provided cmake emits usable .dsp/.dsw files (along with .sln/.vcproj or their successor formats) what is the concern? Please explain "the approach"? At this point the version of MSVS that supports converting .dsp into .sln is nearing extinction if it is not EOL already. The last MSVS to support writing .dsp files is long dead. If cmake is truly capable of emitting these files, there is no justification for them in our source control, is there? What we have cmake generate for a -win32-src.zip distribution file is a topic for another discussion. On Thu, Aug 27, 2015 at 5:51 PM, Steffen <[email protected]> wrote: > 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. > That is the plan, prove it is no longer experimental and meets these goals before we ditch our connection to visual studio for windows developers. I presume most of your comments are in light of building httpd. Note that non-autocruft users have cmake to build modern pcre (8.38 or 10.x which I hope to add support soon). That is fairly straightforward. I haven't tried extracting sln/dsw, but for command line build it is trivial; cd "$(OBJROOT)/pcre" cmake -G "NMake Makefiles" -D CMAKE_INSTALL_PREFIX=..\thirdparty \ -D BUILD_SHARED_LIBS=ON -D CMAKE_BUILD_TYPE=RelWithDebInfo \ -D CMAKE_COLOR_MAKEFILE=OFF -D PCRE_BUILD_PCRECPP=OFF \ -D PCRE_BUILD_PCREGREP=OFF \ -D ZLIB_LIBRARY=../thirdparty/lib/zdll.lib . nmake all install $(INSTALL) "pcre.pdb" "..\thirdparty\bin" $(INSTALL) "pcreposix.pdb" "..\thirdparty\bin" I had to hack the RelWithDebInfo to build a true release binary with separate .pdb, and want to cooerce the NMake Makefiles flavor to emit the copy commands in RelWithDebInfo mode for .pdb alongside .exe, before I send the fix upstream to cmake devs. The best aspect of a cmake-based solution is going to be the ability for the unix-ish folks to also try a cmake build when restructuring things. If it doesn't translate well to windows, we can fix that, but at least they can give it a run within unix.
