Re: find usage of gcov-clean target in Makefile.in

I'm sorry for the delay.

On 2019/11/29 6:17, Daniel Shahaf wrote:
> Yasuhito FUTATSUKI wrote on Fri, Nov 29, 2019 at 00:15:48 +0900:
>> Hi, while I do 'make distclean', I find odd `find' usage.
>>
>> In Makefile.in:
>>> gcov-clean:
>>> rm -f gcov-lcov.dat gcov-lcov.log gcov-genhtml.log
>>> rm -rf gcov-report
>>> find . -name "*.gcda" -o -name "*.gcno" -exec rm -f -- {} \;
>>
>> Is it intended below ?
>> find . \( -name "*.gcda" -o -name "*.gcno" \) -exec rm -f -- {}\;
>
> I believe so, yes. Good catch.
>
>> I also want to insert `-name ".svn" -prune -or ' to avoid searching
>> files into metadata directory in working copy, for I can find it
>> because it takes long time to execute gov-clean target on my jalopy
>> computer :)
>
> Is -prune portable? I don't see it in the POSIX spec of find(1).
>
> Is there a way to avoid find(1) altogether here? For example, by skipping this
> block when gcov hasn't been run, or by hardcoding glob patterns to gcda/gcno
> files, etc?
>
> Would the following be correct? —
> .
> if test -e gcov-report; then
> find . \( -name "*.gcda" -o -name "*.gcno" \) -exec rm -f -- {} \;
> rm -rf gcov-report
> fi
>
> I deliberately did the «rm» after the «find» to make the target
> interruptible/restartable.

Anyway, we should fix this operator priority issue, so I'll do it first.
  
> Alternatively, you could sidestep the problem entirely by doing an out-of-tree
> build and then just rm -rf the builddir. (I always do out-of-tree builds with
> the build tree on a ramdisk; it's far faster this way. That used to be documented
> on http://wiki.apache.org/subversion/BuildNotes, but I'm not sure if that link's
> still valid — it just gives me a login prompt now ☹)

Thanks you, Daniel and Brane, now I can build out of the woking copy.

This need to generate SWIG language bindings C source and support codes
before configure to build them, and then, I awared that
'autogen.sh --release' is now broken on generation of swig-py source
because of SWIG_PY_OPTS variable introduced on swig-py3 branch merge.
SWIG_PY_OPTS variable is now set by configure script, depends on which
is its target py2 or py3, and SWIG version is prior 4.0 or not, however
autogen.sh should be run before configure :)

I ran
"env SWIG_PY_OPTS='-python -py3 -nofastunpack -modern' sh ./autogen.sh"
for work around.

To resolve this problem, I start to try to separate py2 source
directory to store source code generated by SWIG for py2 and make target
to build swig-py2.

Cheers,

-- 
Yasuhito FUTATSUKI <futatuki_at_yf.bsdclub.org>/<futatuki_at_poem.co.jp>