On Sun, Sep 29, 2019 at 6:04 PM sebb <seb...@gmail.com> wrote: > On Sun, 29 Sep 2019 at 22:36, Matt Sicker <boa...@gmail.com> wrote: > > > > I’m sort of going off of what GNU projects do (they use autotools for > any C > > projects), but the common ‘./configure && make && sudo make install’ > > snippet is almost timeless. > > Not sure what that has to do with the question at hand, i.e > > Is the file is allowed to be in the source artifact if it is not in > the source repository? >
For me, no, I expect the source zip/tar to be a subset of what is in the repo for the purposes of building usable artifacts, not a super-set. Gary > > > On Sun, Sep 29, 2019 at 13:01, sebb <seb...@gmail.com> wrote: > > > > > On Sun, 29 Sep 2019 at 17:21, Matt Sicker <boa...@gmail.com> wrote: > > > > > > > > Projects that have a configure script usually include that in the > source > > > > distribution but not in the source repository (at least for autotools > > > > users). > > > > > > But is that correct? > > > > > > Surely the source archive should only contain source that is in the > source > > > repo? > > > > > > Provenance of source is vital: i.e. each file can be found in SVN/Git. > > > > > > > On Sat, Sep 28, 2019 at 17:41, sebb <seb...@gmail.com> wrote: > > > > > > > > > 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 > > > > > > > > > > -- > > > > Matt Sicker <boa...@gmail.com> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
