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.
* 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.
* 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?
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.
* 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'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.
Thanks so much for spending the time!!
No problem, I figured I should give it a whirl.
Gregg
