octave-maintainers
[Top][All Lists]
Advanced

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

Re: octave tools in C++ form


From: Thomas Weber
Subject: Re: octave tools in C++ form
Date: Fri, 08 Dec 2006 09:50:07 +0100

Am Freitag, den 08.12.2006, 02:08 -0500 schrieb John W. Eaton:
> On  7-Dec-2006, Thomas Weber wrote:
> | I routinely open the bash script in an editor to look for paths. It's much 
> | faster than reading the manpage and guessing which variable I'm looking 
> for. 
> 
> Why do you have to guess?  

That's probably a specific problem for package maintainers. For example,
when working on the parallel installation of Octave 2.1 and 2.9 in
Debian, I needed a path with an API-version for the .m files (so that
2.1 didn't try to load files for 2.9 and vice versa). 

> I think this shows that the man page (and text printed by --help) is
>  not good enough.  What information is missing?  

It's not so much what it's missing, but what is there. There are
currently around 30 variables defined. 

By the way, LIBEXECDIR is defined twice, patch attached (though I don't
know if my CVS is current. I can't connect to the server right now. It
seems to be a problem with my side of DNS). 

Variables that in my opinion can go:
MAN*
*EXEC*


> Would it help if it
>  said precisely what commands are run (using the variable names that
>  you can set) and what the default values for those variables are on
>  your system?  

This might make sense, but isn't that the realm of mkoctfile?



> For example, something like

>   C++ files are compiled using the command
> 
>     $CXX -c $CPPFLAGS $CXXPICFLAG $ALL_CXXFLAGS $pass_on_options $incflags 
> $defs $f -o $o
> [snip]
>     $o is the output file name, constructed from the basename of $f


If mkoctfile becomes binary, than yes, this might make sense. 

Thanks
        Thomas


Attachment: octave-config.patch
Description: Text Data


reply via email to

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