You wrote: .... GUI? I realize that GUI operations may be fine for you and Steffan and many others, but a build system that requires manual/GUI intervention is unsuitable for typical release build and packaging requirements.....
I hope Steffan is me and not Stefan F I do for over 10 years “typical release builds” in 12 flavors at www.apachelounge.com with success and is downloaded by millions , I do not see your point that it is unsuitable. Indeed I have a few clicks now, should be easy to make a .bat/powershell to automate. But I do not want that, I want no silence building. Btw: In fact there are one click scripts around (and mentioned here on the list) and I can recall Pierre Joyce who proposed here (no follow up) a new one click build system based on the PHP way. Btw. With cmake you need a lot more keyboard strokes then the few clicks with VC GUI, so what is manual Still investigating the compiler/link/other options cmake uses as said in the other post. In addition to optimization/debug/tracing options, I make on request special builds for specific hardware/processors and/or windows versions, oh so easy now. What do you mean with “package requirement” on Windows I do not know what to package. Or do you mean integrating with other (commercial) software, that is no issue here. They just pick up a build from AL and make an installer around it with their own software. No issues reported by them. Hard to react for me on your other arguments, to technical and mostly developer versus typical windows user/admin. I understand your points from a *nix developer point of few, but please understand that we are not developers but Windows users/admins. Such a discussion can be endless like *.nix versus Win. That you as a developer have problems with Win build system as it now is, is hardly to believe. A .dsp and makefile file is hardly changed all that years and as Gregg said you have to know to find the place where to insert a line for the build system with a new module. And with a new module dsp, Gregg and others can pick it up and you have no worry (open source to help). Off-topic: Coding is an other story, the “if def Win” stuff. I have a good experience with module developers, in an early stage they hand me over the code to test it. I remember the old days when mod_fcgid was not ASF, together with the author we implemented the Win additions/changes. Also mod_security is handed me over before beta/rc I have to say that the Windows community appreciates very much that there is such attention, there where other days. Next week I have time to give cmake a try. Who knows it is not that worse as it looks like now. Regards, Steffen Ps. Still strange that you do not want cmake with *nix. From: Jeff Trawick Sent: Sunday, 1 September, 2013 05:47 To: Apache HTTP Server Development List Subject: *********** Re: will anyone build httpd/apr with cmake on Windows? On Sat, Aug 31, 2013 at 10:09 PM, Gregg Smith <[email protected]> wrote: Hi Jeff, I see Steffen has chimed in and have read the reply as well, but I just want to cover a couple points now, I need to ponder on some of your other comments. On 8/31/2013 2:41 PM, Jeff Trawick wrote: On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <[email protected] <mailto:[email protected]>> wrote: Hi Jeff, Well, putting on my Apache Haus hat my first impressions are "What a nightmare!" :) I must say I prefer the more turnkey approach we enjoy these days, I'm not 100% sure what you mean by the more turnkey approach. I guess that is putting support libraries under httpd/srclib and having the httpd build sort of orchestrate putting the libraries together, installing the stuff httpd cares about, etc? More the fact that httpd, APR, APU & APIconv are built in one click of the build button. Granted, other dependencies have to be built separately including now PCRE as of 2.3. Although I do try to work on Windows from time to time, I am no expert in building and putting together stuff in the current way. Here is my own admittedly ignorant understanding of the current build system (please add corrections): * I have to do multiple conversions of the project files in svn to run with the latest Visual Studio stuff With that obstinate nightmare called VC10, that was the only way I could get it to be successful (converting to VC9 first), VC11 this is not the case. It still has quirks, the intellinonsense in VC11 is a pain, but as long as we regenerate apr/apu.h files during every build, it's going to rebuild those a few times during a single build session. I need to look again and see if it can be disabled though I doubt it. I've worked around it. As Steffen mentioned, it needs a little minor adjusting to get it working. VC11 does not like embedding the manifest in ApacheMonitor, nor does it like using precompiled headers in APR-Iconv. For whatever reason for me, it cannot find libxml2.lib for mod_proxy_html/xml2enc, even though it has no problems with any other modules dependencies . I haven't figured this one out yet. I have to build on a VM somewhere in the world and the added time/complexity has kept me from getting anywhere fast with this. * Manual and/or Visual Studio GUI work is required to build everything using recent Microsoft tools. Huh? Manual? VC GUI yes, because we do not have a full set of nmake makefiles in svn, like there are for APR/APU. GUI? I realize that GUI operations may be fine for you and Steffan and many others, but a build system that requires manual/GUI intervention is unsuitable for typical release build and packaging requirements. Windows build support in httpd/apr is defective if it can't be built with modern Microsoft compilers without manual intervention. That isn't to say, of course, that GUI ways of doing things are bad or inappropriate for the projects to provide. (cmake generates project files too, but somebody that likes to build in the Visual Studio GUI would need to try it and compare.) Surely there's a way to script what you're doing? * I don't understand how to get Makefiles that build things the right way for the latest Microsoft compilers What's "the right way?" If you just mean generating the makefiles, yes, that is M$ deciding to remove the feature after VC6. * There's a high ratio of gorp to critical information in the Windows build files we maintain in svn, and I feel that I'm going to break something every time I try to the required new gorp in order to add a file or module or whatever to the build for Windows. Nah, you've done well so far. Granted, there's only a few lines you need to concern yourself with mostly. CPP, LINK32 & the Source file stuff at the bottom. You handled adding util_fcgi.c to libhttpd with ease it looked! Adding a module is another story I admit. It's more just knowing what and where. There at least are example in the svn of just adding a module. For instance http://svn.apache.org/r1436058 Then there's also the "PING: Windows folks" on dev@ possibility, explaining what was added/subtracted/changed that would require an adjustment to the build. Someone knowing with commit access would see this and gladly make any necessary changes, then again, maybe not. Sometimes I've added things in a way that works, sometimes I've added things in a way that doesn't. I forgot about adding mod_authnz_fcgi.dsp and a reference to it, and nobody else picked up on that either (yet). My recollection is that other people have mixed results too. FWIW, the one line it takes to support that module with cmake is "modules/aaa/mod_authnz_fcgi.c+I+FastCGI authorizer-based authentication and authorization" (Modules which require extra defines or libraries would have another line for every special requirement -- include or define or extra library or prereq.) * People have other build tools on Windows that they want to use, and all that Visual Studio stuff is essentially useless to them except for trying to reverse engineer intention out of the generated gorp; certainly not useful for actually building. (I've only tried "NMake Makefile"-based builds using a mix of 32-bit, 64-bit, Visual Studio 2010 tools, and Visual Studio 2012 tools; I haven't tried non-Microsoft compilers yet.) What people? What other tools? Considering httpd and apr: What people/What other tools on Windows various including some that provided patches/autoconf-based build in Cygwin me + various others including multiple people that provided patches/autoconf-based build using MinGW product I've worked on/Intel compiler using modified VC6-exported makefiles Code can get better when you check it with more compilers. E.g., Windows-specific code in httpd and apr has gotten better based on building with gcc. My build requirements that aren't met with the current system: * statically linking third-party modules with the server (e.g., including in libhttpd, editing modules.c) * fine-grained control over which modules are built and which are loaded by default Who am I to decide just what 3rd party modules my users want to use. Not only that, when there is a new version of a module, do I really want to rebuild and entire Apache? No, I just build the new version of the module. That way if Joe User doesn't want mod_auth_ntlm, he doesn't have to download it and add it to his Apache and it doesn't have to be absorbing space on the hard drive. I do understand this ability is possible in the unix build though, I've built on Linux a couple times. I really do get it and the admin whos corporate policy is to download only from ASF or build it in house could have use for this. FWIW, that's not something you do with mod_php or such. One particular case: it can be useful to augment the core server with additional code, and organizing it as a statically linked module gets you most of the integration points for free. The autoconf-based build had support for that all long. At any rate, I use it, you don't, peace on earth ;) * absolutely no requirement to put support libraries in srclib/* I actually had a php developer ask me why we didn't use just a *single* dependency tree; /deps /deps/bin /deps/include /deps/lib the only answer I came up with was "because this works!" * ability to build for Windows and various Unixy platforms using the same basic flow No comment. But really, who is going to use this on Windows? Who are the noobs? Developers? The noobs are Joe Windows Apache User who one day decides to grab a free copy of VC++ Express and give it a whirl. I was that person once long ago in the 1.3 days. If only there were express versions back then. Perhaps I'm misunderstanding something, but installing support libraries to the same prefix lets cmake find stuff with zero code, and the intention is to put things in the same prefix anyway, right? If you wanted to put the sources under srclib but still install to the same prefix it still works? I get it now and that was mostly what I had, my downfall was using -D pointing to optional library folders instead of library files (my bad). Somehow I think that a wrapper script/makefiles to put together the independent builds of the various projects is the missing piece to a lot of these concerns. I would have thought that different developers/bundlers/etc. would have their own way to glue things together that makes sense for them, but perhaps some default is needed. See makefile.win, it's all there. Installs all the mess including any optional DLLs to where they belong. I certainly agree with the value of having a makefile/script which pulls it all together. Tying all the existing Windows build together without that is about like doing the same with cmake. I've never actually "nmake install" any dependency, it's rather useless on Windows. I have to create multiple mod_ssl with different openssl versions so installing openssl would limit that. This might help you understand my suggestion about dependencies :) I guess with the cmake build of httpd you start with these openssl builds or installs (whatever it takes for FindOpenSSL to deal with): \openssl1 \openssl2 \openssl3 You build httpd once using the desired feature set and you specify one of these openssl trees with the cmake settings CMAKE_LIBRARY_PATH/CMAKE_INCLUDE_PATH. Rename that first mod_ssl.so mod_ssl_for_openssl1.so Build httpd two more times using minimal feature set (save build time), setting the CMAKE path used to find prereqs to those other builds of openssl. ARGH! I do somewhat similar though, yours just sounds harder. How does that work for you today? How much code gets rebuilt as you prepare the additional mod_ssl builds? 2 OpenSSL builds in srclib, one named openssl and another named openssl-x (x being 098 or 101). Build Apache and Install. Rename the OpenSSL folders, change Install folder, rebuild just the few items that actually link to OpenSSL, Install again. GUI is handy for this since you can rebuild a single project easily. This is driven mainly because of mod_php, PHP 5.4 links to OSSL 0.9.8 so if Apache is built with 1.0.1, it will not start. We offer downgrade zips for this purpose. mod_fcgid remedies this problem but some people would rather use mod_php. Sorry, but I just gotta say it -- when you write "GUI is handy" I read "unrepeatable procedure that can't be stored in version control" or, at best, "hard-to-maintain GUI driver script that presses buttons " Why isn't something that the computer does for you automatically while you do something that humans are good at easier than something that requires you to press buttons at certain points? Thanks so much for spending the time!! No problem, I figured I should give it a whirl. Gregg Best wishes! -- Born in Roswell... married an alien... http://emptyhammock.com/
<<wlEmoticon-smile[1].png>>
