On Sat, 28 Sep 2019 at 17:42, Mark Thomas <ma...@apache.org> wrote: > > On 28/09/2019 17:06, Gary Gregory wrote: > > On Sat, Sep 28, 2019 at 12:04 PM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > >> I can confirm that if I delete all of: > >> > >> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE > >> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE > >> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE > >> > >> I can build without errors but with warnings: > >> > >> .\..\..\apps\prunsrv\prunsrv.c(323): warning C4996: '_wfopen': This > >> function or variable may be unsafe. Consider using _wfopen_s instead. To > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for > >> details. > >> C:\Program Files (x86)\Windows > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see > >> declaration of '_wfopen' > >> .\..\..\apps\prunsrv\prunsrv.c(347): warning C4996: '_wfopen': This > >> function or variable may be unsafe. Consider using _wfopen_s instead. To > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for > >> details. > >> C:\Program Files (x86)\Windows > >> Kits\10\include\10.0.17763.0\ucrt\corecrt_wstdio.h(130): note: see > >> declaration of '_wfopen' > >> .\..\..\apps\prunsrv\prunsrv.c(1339): warning C4996: '_snprintf': This > >> function or variable may be unsafe. Consider using _snprintf_s instead. To > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for > >> details. > >> C:\Program Files (x86)\Windows > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of > >> '_snprintf' > >> .\..\..\apps\prunsrv\prunsrv.c(1341): warning C4996: '_snprintf': This > >> function or variable may be unsafe. Consider using _snprintf_s instead. To > >> disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for > >> details. > >> C:\Program Files (x86)\Windows > >> Kits\10\include\10.0.17763.0\ucrt\stdio.h(1961): note: see declaration of > >> '_snprintf' > >> rc /l 0x409 /d "NDEBUG" /i ".\..\..\include" /fo > >> WINXP_X86_EXE_RELEASE\prunsrv.res .\..\../apps/prunsrv/prunsrv.rc > >> > > > > FWIW, using: > > > > Microsoft (R) C/C++ Optimizing Compiler Version 19.21.27702.2 for x86 > > Copyright (C) Microsoft Corporation. All rights reserved. > > Since I am going to re-tag for an RC2 (see below) I'll see what I can do > to clean up those warnings. > > >> On Sat, Sep 28, 2019 at 11:53 AM Gary Gregory <garydgreg...@gmail.com> > >> wrote: > >>> On Sat, Sep 28, 2019 at 10:03 AM sebb <seb...@gmail.com> wrote: > >>>> On Sat, 28 Sep 2019 at 13:39, Gary Gregory <garydgreg...@gmail.com> > >>>> wrote: > > <snip/> > > >>>>> It seems we should NOT deliver the following folders in the src zip > >>>> which > >>>>> now contain objs and exes: > >>>>> > >>>>> src\native\windows\apps\prunmgr\WINXP_X86_GUI_RELEASE > >>>>> src\native\windows\apps\prunsrv\WINXP_X86_EXE_RELEASE > >>>>> src\native\windows\apps\prunsrv\WINXP_X64_EXE_RELEASE > >>>>> > >>>>> WDYT? > >>>> > >>>> Looks like the build created the files in the wrong directories? > > They should not be present in the source zip. I normally build the > binaries from the same tag but in a completely different checkout to > avoid this sort of thing. I'll see if I can figure out what I did wrong > but regardless of whether I can or not, I'll cancel this release, update > the estimated release date, re-tag and start an RC2 vote. > > I'll also take a brief look at whether I can exclude those directories > explicitly from the source build to avoid this issue in future although > my Maven foo may not be up to that. >
Why not create them in a different output directory under target? > >>>> The src zip also contains: > >>>> src/native/unix/configure > >>>> AIUI this is a generated file; I would expect it to be in the binary > >>>> artifact, if anywhere > > No. The configure script is generated but it *is* meant to be in the > source distribution. Without it, building from source is more difficult. > I forgot this for the 1.2.0 release and there were complaints as a result. Is the config file OS and version independent? If not, then it might be confusing. Why is it not in the Git repo? > >>>> Also there are some Git files missing from the src zip. > >>>> Not sure if that is intentional? > >>>> > >>>> CONTRIBUTING.md > >>>> HOWTO-RELEASE.txt > >>>> README.md > >>>> > >>> > >>> I certainly would expect CONTRIBUTING.md and README.md to be in the src > >>> zip, not quite a blocker for me. I am more concerned that we are including > >>> all of these OBJ and EXE files. > > The .md files are generated but I agree they should be in the source > distribution. I'll see about getting them added. > > The HOWTO_RELEASE.txt is perhaps more debatable but on balance I think > it should be there too. Does no harm, and makes it easier to compare source tag with source bundle. > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
