httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: will anyone build httpd/apr with cmake on Windows?
Date Tue, 03 Sep 2013 11:29:16 GMT
On Tue, Sep 3, 2013 at 7:27 AM, Jeff Trawick <trawick@gmail.com> wrote:

> On Tue, Sep 3, 2013 at 5:06 AM, Steffen <info@apachelounge.com> 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/

Mime
View raw message