On Tue, Sep 3, 2013 at 7:27 AM, Jeff Trawick <[email protected]> wrote:
> 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 > I meant simply "end user should not invoke cmake directly" > 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/ > -- Born in Roswell... married an alien... http://emptyhammock.com/
