Ok, thanks for the clarification.
Cheers,
Gregg
On 2/25/2018 3:30 PM, William A Rowe Jr wrote:
No,
Community process. I am going to beg to restore sanity for all our
developers, not relying on any one person, and we are going to strive at a
community decision before 2.next GA, whether my suggestions carry, or not.
One of those suggestions is that win32 do nothing that the unix build
schema refused to. For 18 years we faithfully delivered a LICENSE and later
a NOTICE to the build result tree.
I've raised this repeatedly and the vast majority of the PMC does not care.
Until unix builds bother, it is time to drop this maintenance headache of
depositing the Apache License and NOTICE, nevermind appending third party
artifacts in the win32 schema.
On the topic of splitting the many-other-ways to build win32, I'm not only
supportive of your efforts to maintain this, but am willing to participate
now that I'm in sync again with modern MSVC/Studio. I'll share pointers
once my testing is complete of baby+bathwater solution to all the
prerequisite components. All I suggest is that it can sit in parallel and
be fixed both before and after release, instead of burning rev no's on
nearly every candidate.
Thanks for your efforts and enthusiasm Gregg, I'm not about to start
ignoring your input,
Cheers
Bill
On Feb 25, 2018 14:17, "Gregg Smith" <[email protected]> wrote:
On 2/23/2018 10:24 AM, William A Rowe Jr wrote:
On Fri, Feb 23, 2018 at 12:01 PM, Steffen <[email protected]> wrote:
Op 18 feb. 2018 om 17:57 heeft Eric Covener <[email protected]> het
volgende geschreven:
On Sun, Feb 18, 2018 at 11:53 AM, Steffen <[email protected]> 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.
