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/
