On Tue, Sep 3, 2013 at 5:06 AM, Steffen <[email protected]> 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. > You could look at it that way. For some of us it is just an unspoken core requirement that you can do such a thing. I also understand that it must have suitable defaults so that a user can say "go" without spending 2 hours reading documentation. > > 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 >> > Hopefully there will be multiple expressions/philosophies of how to use the independent builds of the various projects, but what you describe should be possible. But I think the end user script/Makefile should not invoke cmake directly if the end user is going to use the typical philosophy (nmake makefiles, install projects together, etc.). Imagine a clever makefile/script that lets the user do nmake BUILDTYPE=Rel|Debug DOWNLOADDIR=c:\downloads PREFIX=c:\httpd24 and everything in the download dir (libxml2, zlib, apr, apr-util, openssl, httpd, etc.) that it knows about gets built in some standard way and httpd features and apr-util get turned on accordingly based on what support libraries are there. Somebody should be able to script a GUI (not the cmake GUI ;) ) which lets users select high-level features and ensures that they have the source (or download it), and then uses the flexible underlying build of each project to do the right thing. We have to have a lot of flexibility in the underlying project builds to support different classes of users or tooling or packaging requirements, which in turn leads to options that a lot of people won't use, and that potentially confuse people if there aren't suitable defaults and some doc that says "here's how most people build it." Unfortunately we're still a ways from getting enough features supported/tested/debugged with the cmake builds for wide use, so I'm still mostly worried about the flexibility aspect. > > Steffen > > > ps. > Still no able to build with your current cmake files, errors that > apr/include is not correct. Asked Tom D for help. > Was that when building httpd? Maybe it couldn't find an apr header file with "arch" or "private" in the name? -- Born in Roswell... married an alien... http://emptyhammock.com/
