On 2/23/2018 10:24 AM, William A Rowe Jr wrote:
On Fri, Feb 23, 2018 at 12:01 PM, Steffen <i...@apachelounge.com> wrote:

Op 18 feb. 2018 om 17:57 heeft Eric Covener <cove...@gmail.com> het volgende 
geschreven:

On Sun, Feb 18, 2018 at 11:53 AM, Steffen <i...@apachelounge.com> 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:

http://www.apache.org/dev/licensing-howto.html#mod-notice
```
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 Makefile.win in SVN contains the text,for example see below.



!IF EXIST("srclib\nghttp2")
type << >> "$(INSTDIR)\NOTICE.txt"

This binary distribution of mod_http2.so includes nghttp2 C library written
by Tatsuhiro Tsujikawa. For complete information, visit nghttp2's web site
at https://nghttp2.org/
<<
-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 makefile.win, 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 correctly?


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

InstallBin is just nmake _install, so there's no difference.
# PROP Cmd_Line "NMAKE /f makefile.win 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 Makefile.win 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.


Reply via email to