On Tue, Sep 3, 2013 at 4:41 PM, Tom Donovan <donovant@bellatlantic.net>wrote:
> On 09/03/2013 05:06 AM, Steffen wrote:
> >> On 8/30/2013 5:25 AM, Jeff Trawick wrote:
> >>
> >> Please let me know if you
> >>
> >> * are waiting for some certain feature (other than near perfection)
> before
> >> you use it
> >
> >
> > After some days puzzling, I realize now that it looks like you want to
> > accomplish an ASF Buildbot for Windows, like the buildbot that currently
> > builds on multiple *nix OSs, can be very useful for the ASF. If you
> would
> > have made that clear in the beginning, I might not of spoke much, that
> may
> > have been said earlier and I missed it.
> >
> > I like to see on top of that a more user/admin friendly way, which is a
> > more in line with the current system and should more easy to
> > migrate/understand for them and should not so complex for a general
> > user/admin.
> >
> > I was thinking:
> >
> > Dependencies still in httpd/srclib (I understood that Tom D advises this)
> > and build manually, like now, pcre, libxml2, openssl, zlib, lua etc.
> >
> > And then a command line like:
> >
> > CMAKE -G "NMake Makefiles" \ -DBUILDTYPE=Rel|Debug|..| \
> > -DINSTDIR=Path \
> > -DSOLUTION=|Buildbin|Buildall|Installbin| \
> > -DDBLIST=|..|..|
> >
> > note: Plus the current options: PORT SSLPORT DOMAINNAME SERVERNAME
> > SERVERNAME (not defined use defaults)
> >
> > And then to build:
> >
> >> NMAKE
> >
> >
> > Steffen
> >
> >
> > ps.
> > Still no able to build with your current cmake files, errors that
> > apr/include is not correct. Asked Tom D for help.
> >
> >
> Steffen,
>
> I think you have shown us the underlying misunderstanding here. I guess
> what you expected (and what
> I started building last spring) was a CMake build system that did, at a
> minimum, this:
>
> * after building the prerequisite libraries,
> generate a single MSVC solution file for either vc9, vc10, or vc11
> (and soon vc12)
>
> * this solution would build httpd & apr in a single pass in MS Visual
> Studio
> (and for versions 2.4 and earlier, also build apr-util and apr-iconv)
>
> * this solution would have an install project which:
> * creates a directory and installs a complete working httpd system into
> it
> * can safely be re-installed to the same location (doesn't clobber
> .conf files, etc.)
> * does not install any files which do not belong in an httpd system
> (i.e. no header or lib files from prerequisites, etc.)
>
> I was pleased that Makefiles are a free byproduct of using CMake because,
> like Jeff, I almost always
> use automated builds and Makefiles whenever I can. I use the GUI for
> profiling and debugging. I
> did not, however, consider myself to be the "target audience" for this
> CMake effort.
>
> I think that Jeff has a different goal altogether. Since I never
> followed up on my CMake efforts,
> and Jeff took the lead here - this project will just need to go with his
> decisions, rather than my
> assumptions and yours. Like you, I'm disappointed; but those who do the
> actual work (i.e. Jeff)
> get to make the actual decisions (i.e. BuildBot vs. users' expectations).
>
Maybe the misunderstanding is all on my side, but I think all the end goals
and some of the lower-level details you mention can build on top of cmake
lists that themselves don't embody that or any other specific philosophy of
how to combine independent projects.
Just consider the aspect of "cluttering" the install prefix with parts of
pcre/zlib/etc. that httpd doesn't need:
I don't think that the core of the build for httpd should "know" what parts
of OpenSSL or pcre or libxml should be installed on behalf of it. But
there's no reason that a top-level Makefile.win/script/whatever can't do
that, after installing those support libs to a different prefix.
Stray comments (i.e., not going through each issue one by one):
The current cmake for httpd can install the complete httpd bits (or pretty
close if you ignore certain modules it doesn't know how to build), and can
safely be re-installed to the same location (unless there is a bug). I
guess it isn't a separate "install project" though it is performed with a
different target when I use makefiles. cmake knows it is an install task,
but I haven't played with the Visual Studio project generation to know if
cmake creates separate Visual Studio targets for install that can be
selected or unselected at will. (Maybe that's not at all what you refer
to.)
I'm not sure about the "single pass" Visual Studio solution possibilities.
Maybe cmake isn't the implementation mechanism for grouping the different
Visual Studio solutions together, just as it isn't the implementation
mechanism for the top-level script/Makefile.win. Or maybe there can be a
top-level cmake list that does exactly that by referencing the other cmake
lists.
End user expectations in general: top-level scripts/Makefile.win/whatever
> Jeff - I haven't got your CMake build to work yet; and I confess that once
> I realized we had such a
> different idea of the end result, my enthusiasm has waned. Nevertheless,
> I'll make some time to
> continue to try - probably next weekend - and let you know how I fare with
> it.
>
Cool...
>
> Regards,
> -tom-
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/