> On Sep 29, 2019, at 5:36 PM, 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.
> 

+1 to that

>> 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

Reply via email to