Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of margol@beamartyr.net
 designates 85.195.98.136 as permitted sender)
Message-ID: <4F9A34CA.2000902@beamartyr.net>
Date: Fri, 27 Apr 2012 08:55:22 +0300
From: Issac Goldstand <margol@beamartyr.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: packaging libapreq2 as a dependency
References: <1335492759.77968.YahooMailNeo@web160901.mail.bf1.yahoo.com>
In-Reply-To: <1335492759.77968.YahooMailNeo@web160901.mail.bf1.yahoo.com>
Content-Type: multipart/alternative;
 boundary="------------020706060906000208000103"

This is a multi-part message in MIME format.
--------------020706060906000208000103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 27/04/2012 05:12, Joe Schaefer wrote:
> Now that some time has passed since Philip brought
> apreq2 into trunk it's probably a good time to discuss
> how best to incorporate it into httpd itself.  Right
> now the library files are in server/ which basically
> means we're internally compiling libapreq2 into httpd.
>
> Personally I'd prefer to see libapreq2 bundled as an
> upstream dependency, ie put the library into an associated
> deps package or just something in srclib/ so it will
> provide an independent library file (static, dynamic, or both)
> so all users including httpd can link to that object. The
> apreq devs spent a considerable amount of time writing
> the apreq module api so people could use apreq in any
> C context- within an httpd module, a CGI script, or an
> fcgi daemon.  It'd be nice to preserve that flexibility
> going forward.
>
> Anyway I'm certainly willing to work on libapreq's build system
> so it will not be dependent on apxs- it should be really easy
> to do given that we just need apxs in a very limited way (basically
> to get at the apr-*-config package scripts), I
> just need to make the apache2 module build optional so just
> the library gets built.  That would entail pulling the apreq
> source files out of server/ and just leaving the apreq2
> filter module as part of httpd's build system.
>
>
+0

I'm +1 for splitting and putting apreq2 filter in the build system; it's
what to do with libapreq2 that holds me back...

I don't like the idea of "yet another library/dependency" for building
httpd, but after thinking about it, I probably wouldn't want it as more
clutter either in APR or in libhttpd either.  I'd likely change that to
a +1 on the whole if I had even a whisper of a rumor if anyone (other
than the mod_perl folks) was planning on incorporating apreq into some
existing software to justify it being a standalone library.  I know we
built for it, but I've yet to see real adoption.

  Issac

--------------020706060906000208000103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 27/04/2012 05:12, Joe Schaefer wrote:
    <blockquote
      cite="mid:1335492759.77968.YahooMailNeo@web160901.mail.bf1.yahoo.com"
      type="cite">
      <div style="color:#000; background-color:#fff;
        font-family:courier, monaco, monospace,
        sans-serif;font-size:12pt">
        <div>Now that some time has passed since Philip brought</div>
        <div>apreq2 into trunk it's probably a good time to discuss</div>
        <div>how best to incorporate it into httpd itself.&nbsp; Right</div>
        <div>now the library files are in server/ which basically</div>
        <div>means we're internally compiling libapreq2 into httpd.</div>
        <div><br>
        </div>
        <div>Personally I'd prefer to see libapreq2 bundled as an</div>
        <div>upstream dependency, ie put the library into an associated</div>
        <div>deps package or just something in srclib/ so it will</div>
        <div>provide an independent library file (static, dynamic, or
          both)</div>
        <div>so all users including httpd can link to that object. The<br>
        </div>
        <div>apreq devs spent a considerable amount of time writing</div>
        <div>the apreq module api so people could use apreq in any</div>
        <div>C context- within an httpd module, a CGI script, or an</div>
        <div>fcgi daemon.&nbsp; It'd be nice to preserve that flexibility</div>
        <div>going forward.</div>
        <div><br>
        </div>
        <div>Anyway I'm certainly willing to work on libapreq's build
          system</div>
        <div>so it will not be dependent on apxs- it should be really
          easy</div>
        <div>to do given that we just need apxs in a very limited way
          (basically</div>
        <div>to get at the apr-*-config package scripts), I</div>
        <div>just need to make the apache2 module build optional so just</div>
        <div>the library gets built.&nbsp; That would entail pulling the
          apreq</div>
        <div>source files out of server/ and just leaving the apreq2</div>
        <div>filter module as part of httpd's build system.<br>
        </div>
        <div><br>
        </div>
        <br>
      </div>
    </blockquote>
    +0<br>
    <br>
    I'm +1 for splitting and putting apreq2 filter in the build system;
    it's what to do with libapreq2 that holds me back...<br>
    <br>
    I don't like the idea of "yet another library/dependency" for
    building httpd, but after thinking about it, I probably wouldn't
    want it as more clutter either in APR or in libhttpd either.&nbsp; I'd
    likely change that to a +1 on the whole if I had even a whisper of a
    rumor if anyone (other than the mod_perl folks) was planning on
    incorporating apreq into some existing software to justify it being
    a standalone library.&nbsp; I know we built for it, but I've yet to see
    real adoption.<br>
    <br>
    &nbsp; Issac<br>
  </body>
</html>

--------------020706060906000208000103--