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.

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>

Reply via email to