httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Smith <>
Subject Re: Current branche 2.4.30-dev issues
Date Sun, 25 Feb 2018 20:17:38 GMT
On 2/23/2018 10:24 AM, William A Rowe Jr wrote:
> On Fri, Feb 23, 2018 at 12:01 PM, Steffen <> wrote:
>>> Op 18 feb. 2018 om 17:57 heeft Eric Covener <> het volgende
>>>> On Sun, Feb 18, 2018 at 11:53 AM, Steffen <> wrote:
>>>> On Sunday 18/02/2018 at 17:39, Eric Covener wrote:
>>>> -- not sure, mod_md; should curl and jansson be added to notice/license
>>>> files ?
>>>> I don't think either is contained in mod_md, so I don't think they
>>>> should be referenced in the NOTICES:
>>>> ```
>>>> Dependencies which are not included in the distribution MUST NOT be
>>>> added to LICENSE and NOTICE. As far as LICENSE and NOTICE are
>>>> concerned, only bundled bits matter.
>>>> ```
>>>> On Win the curl and jansson dependencies are included in the binary
>>>> distribution.
>>>> We can't reflect what might be added in a third-party binary
>>>> distribution to the NOTICES file in httpd SVN. I think the obligation
>>>> is on whoever creates the binary distribution to enumerate what's in
>>>> it. That's what the ASF policy (same page) would be, at least.
>>>> Till now in SVN contains the text,for example see below.
>>>> !IF EXIST("srclib\nghttp2")
>>>> type << >> "$(INSTDIR)\NOTICE.txt"
>>>> This binary distribution of includes nghttp2 C library written
>>>> by Tatsuhiro Tsujikawa. For complete information, visit nghttp2's web site
>>>> at
>>>> <<
>>>> -awk -f <<script.awk < "srclib\nghttp2\COPYING" >> "$(INSTDIR)\LICENSE.txt"
>>>> BEGIN {
>>>>     print "";
>>>>     print "For the mod_http2 component:";
>>>>     print "";
>>>>     while ( getline > 0 ) {
>>>> print $$0;
>>>>     }
>>>>     exit 0;
>>>> }
>>>> <<
>>>> !ENDIF
>>> Are you asking if it would be appropriate to do the same thing for the
>>> other dependencies?  If they're built the same way it would seem
>>> reasonable.  I do not personally think it's necessary  (showstopper)
>>> for a release. It looks like a convenience for someone who already
>>> copied prereqs into srclib/.  Maybe others feel differently?
>> Bill and others, what do you think ?
> I am getting to snapshot testing in about an hour here on Windows,
> I'm just finishing up my review of 2.4.30 on Linux. I'll have more to
> offer, then.
>> I think to be in line with other deps (like brotli, http2...) we should add it to, which copies to notice/license.
> These are all legacies of having a command line build schema
> for httpd-project distributed windows binaries, which handled the
> vast amount of target tree preparation by presuming each of these
> components exist within srcdir/. That's an extremely inflexible
> mechanism that must be cleaned up in trunk.

So basically what your saying is that if I put any time into getting 
trunk building again (have already done with exception of apreq & now 
proxy_uwsgi), it's all for not and just a waste of my time because 
you're going to toss it all out in the end. Am I understanding this 

> I'm unclear of your build process, whether you are using the SLN
> schema of Or using the GUI results and then just
> using the nmake install step of

InstallBin is just nmake _install, so there's no difference.
# PROP Cmd_Line "NMAKE /f INSTDIR="\Apache24" SHORT=R 
LONG=Release _install"

And since nmake _install has a dependency to nmake _build(r/d) (like 
InstallBin to BuildBin), it would just builds everything again if you 
used nmake install(r/d) after building with the GUI.

> In any case, for those components which the does
> physically copy into the target tree, it ought to also be appending
> the NOTICE. Where it does not take responsibility to move the
> third party lib, it should not extend the NOTICE. Does that seem
> rational?
> We (httpd source tree maintainers) should be out of the business
> of handling 'make install' steps for third party packages. As a
> distributor, I'm sure you and others appreciate the current
> convenience, but it involves generally knowing which rev level
> each third party package is at, and distributors can and will
> disagree on which components and versions should be linked
> into their own build of httpd for their purposes. > > I'm happy to collaborate
on such helpful scripts and utilities but
> they belong out of the /httpd/httpd/branches/rev/ tree so that they
> don't interfere with the release cycle of the primary source project.

View raw message