What to do with builtin functions not in libinterp subdirectory

[Daniel J Sebald]

John,

I've got a problem for you to think about.  I've been experimenting with 
writing some builtin functions utilizing the Qt libraries.  My thought 
was to place this code in

libgui/fcn

which keeps it out of the core Octave source tree.  I've copied the 
parts of libinterp/Makefile.am that search for .cc files in libgui/fcn 
having builtin DEFUN, create .df files, etc.  OK, that goes well 
creating a "builtins.cc" with:

void
install_builtins (void)
{
  install_dialog_fcns ();

  install_built_in_docstrings ();
}

at the end.

The problem is the non-uniqueness of the function name 
"install_builtins" when linking with the call in octave.cc.  So there 
are some things to think about.  Right now, any builtin functions need 
to be in a subdirectory of libinterp, but I don't think that in the long 
run that is a good restriction.  I don't think we want UI C++ code in 
the libinterp subdirectory, do we?  That is sort of messy.  Or even some 
kind of directory name there within pointing to something outside of the 
libinterp tree.  The bad thing about what I've done so far is 
replicating a lot of hard-to-follow code in the libgui/Makefile.am.

What kind of solution can we come up with?  I'm thinking

1) Some kind of utility that does what libinterp/Makefile.am is 
currently doing, or move that code as a definition to the top level Make 
constructs so that it can be used in directories other than libinterp.

2) Attach the directory name as part of the function name inside the 
builtins.cc, e.g.,:

void
install_libinterp_builtins (void)
{
...
}

void
install_libgui_builtins (void)
{
...
}

3) Somehow in octave.cc put a hook that runs

install_libinterp_builtins ();
install_libgui_builtins ();

either by a short little include file or something similar.

Dan