octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cp -a --update


From: John W. Eaton
Subject: Re: cp -a --update
Date: Fri, 11 Dec 2009 16:39:00 -0500

On 11-Dec-2009, Rik wrote:

| John W. Eaton wrote:
| > A recent change you made introduced cp -a --update to the src and
| > scripts Makefiles.  I don't think these options to cp are portable, so
| > I checked in the following change.
| >
| >   http://hg.savannah.gnu.org/hgweb/octave/rev/a7e288044ef7
| >
| > I think the new set of tests combined with cp and touch have the
| > equivalent effect, but should be portable.  Do you see any problem
| > with this solution?
| >   
| No.  I checked the GNU version of 'cp' because the Octave project is so
| GNU-centric and they supported the update option.  I had also considered
| implementing the feature in exactly the way you eventually implemented
| it, but I was mostly happy to have gotten VPATH builds working so I
| didn't bother. 
| 
| I'd also like your opinion on another simplification project I'm
| considering.  Currently the DOCSTRINGS file in the scripts directory is
| generated in a most convoluted way.  The Makefile invokes mkdoc which is
| a shell script.  The shell script is trivial and in turn calls a Perl
| program which it defines on the command line.  The Perl program then
| calls the C program gethelp.  The C program is being used for text
| processing to grab the Texinfo section from the .m files.  Given that
| Perl is extremely good at text processing and is a superset of any
| shell, I would like to collapse everything into a single Perl script. 
| Are there any objections?

I do agree that we could do better than the current solution.

The original reason for the gethelp program was so that we would be
using the same code to extract help text as is used in the Octave
interpreter.  But the code there is just copied, so it may not be in
sync now.  I guess gethelp should really be linked with liboctinterp
and just use the internal functions directly.

Now that Octave has functions to do regexp substitutions and some
functions in to extract Texinfo help strings, maybe we should just use
Octave to do the job?  Although it might be slower than Perl, it would
have the advantage of using the same code that Octave uses to extract
the help text and it would also ensure that Octave can cleanly parse
all the user-callable functions that we distribute.

Please copy future replies to the list so that others may comment.

Thanks,

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]