~/.octaverc overwrites OCTAVE_PATH!!

[Ben Abbott]

On Dec 22, 2008, at 5:34 PM, Rosen Diankov wrote:

>
> 2008/12/22 Ben Abbott <bpabbott at mac.com>:
>>
>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>
>>> 2008/12/21 Ben Abbott <bpabbott at mac.com>:
>>>>
>>>> On Dec 21, 2008, at 3:38 PM, Rosen Diankov wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm trying to append my own directory with octave files
>>>>> (/usr/local/myoctavefiles) to the automatically set octave  
>>>>> paths. At
>>>>> first, I tried doing
>>>>>
>>>>> export OCTAVE_PATH=/usr/local/myoctavefiles
>>>>>
>>>>> but it didn't work since the auto-generated ~/.octaverc file (from
>>>>> savepath) overwrites any added paths via the path function. Ie,  
>>>>> the
>>>>> ~/.octaverc file looks like:
>>>>>
>>>>> ## Begin savepath auto-created section, do not edit
>>>>> path ('/usr/local/share/...',...)
>>>>> ## End savepath auto-created section
>>>>>
>>>>> So the next obvious thing to do was to call
>>>>> addpath('/usr/local/myoctavefiles') right after the '## End  
>>>>> savepath
>>>>> ...', but this has a very dangerous side-effect. The problem is  
>>>>> that
>>>>> the next time the user calls 'savepath', it will put
>>>>> /usr/local/myoctavefiles inside the auto-generated code. And  
>>>>> even if I
>>>>> remove my addpath or set OCTAVE_PATH to something different, my  
>>>>> path
>>>>> will remain added to the octave path!
>>>>>
>>>>> So I propose a small savepath change that always puts
>>>>> getenv('OCTAVE_PATH') inside the auto-generated code.
>>>>> It would be great if this makes it into octave 3.0.4
>>>>>
>>>>> thank you,
>>>>> rosen diankov
>>>>
>>>> If I understand you correctly you'd like to be able to  
>>>> dynamically add a
>>>> specific path when octave is run. Have you looked at the command  
>>>> line
>>>> options. For example,
>>>>
>>>>     octave --path "/usr/local/myoctavefiles"
>>>>
>>>> Other command line options are detailed at the link below.
>>>>
>>>>
>>>>
>>>> http://www.gnu.org/software/octave/doc/interpreter/Command-Line-Options.html#Command-Line-Options
>>>>
>>>> Ben
>>
>>>
>>> It doesn't work, the ~/.octaverc file overwrites any paths from
>>> OCTAVE_PATH, -p, or --path because savepath directly calls path. it
>>> would be great if at least it called addpath.
>>>
>>> rosen,
>>
>> Do you mean you'd like to have the lines added to .octaverc by  
>> savepath use
>> "addpath(...)" rather than "path(...)"?
>>
>> sigh ... I find the savepath command more trouble that it is  
>> worth :-(
>>
>> You may find the best solution it to modify .octaverc by manually  
>> and use
>> addpath() to include your local octave directories.
>>
>> In any event, we will want to be compatible with matlab. Does  
>> matlab provide
>> the functionality you're looking for?
>>
>> Ben
>>
>
> I agree with you. the current savepath does break some things about
> the flow of paths in octave. We recently started using octave for a
> robotics framework ROS
> (http://pr.willowgarage.com/wiki/rosoct#preview) and we are starting
> to create many packages that optionally have octave code that use a
> core ROS 'octave library'. In order for those functions to be visible
> in octave, they have to be added to the path, so I would like the
> users to be able to add a simple
>
> export OCTAVE_PATH=...
>
> in their .bashrc that automatically finds the correct directory and
> includes it. The path will be dependent on the particular directory
> their checkout tree lies in (which can change).
>
> The problem with savepath is that it sucks in the current paths into
> its one 'path' call, which makes using multiple build trees of the
> robotics framework very hard.
>
> According to the matlab savepath, there is a separate 'userpath'
> variable that gets combined with the current paths.
>
> Ideally, savepath would remove all directories in OCTAVE_PATH before
> making the addpath call (there's no reason it should be calling path).
>
> thanks,
> rosen,

A proper fix will be slightly more a bit more difficult than patching  
savepath.m. In addition to OCTAVE_PATH a proper solution should also  
treat the command line path option in the same fashion. My c/c++  
skills are essentially non-existent, but this looks like a simple task  
(maybe even I can manage it).

What is needed it to make the "tpath" in load_path::do_initialize  of  
load-path.cc were available to m-files.

----------------------
   std::string tpath = load_path::command_line_path;

   if (tpath.empty ())
     tpath = octave_env::getenv ("OCTAVE_PATH");
----------------------

Can anyone tell me if such is *already* available to m-files. I'd  
tried adding the code below to load-path.cc, but it doesn't work ...  
which I expect demonstrates my c/c++ incompetence ;-)

----------------------
DEFUN (commandlinepath, , ,
     "-*- texinfo -*-\n\
@deftypefn {Built-in Function} {} commandlinepath (@dots{})\n\
Return the command line path variable.\n\
\n\
@seealso{path, addpath, rmpath, genpath, pathdef, savepath, pathsep}\n\
@end deftypefn")
{
   return octave_value (load_path::command_line_path);
}
----------------------

Can someone enlighten me as to what I'm doing wrong? ... a "make" from  
the src directory produces the result below.

----------------------
$ make
making defaults.h from defaults.h.in
defaults.h is unchanged
make: --cppflags: Command not found
make: --ldflags: Command not found
making oct-conf.h from oct-conf.h.in
oct-conf.h is unchanged
g++ -c -g -I/sw/include -FOpenGL -I/sw/include/freetype2 -I/sw/include  
-fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc  - 
DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2  
load-path.cc -o pic/load-path.o
load-path.cc: In function ‘octave_value_list Fcommandlinepath(const  
octave_value_list&, int)’:
load-path.cc:48: error: ‘std::string load_path::command_line_path’ is  
private
load-path.cc:1783: error: within this context
make: *** [pic/load-path.o] Error 1
----------------------

Ben