Re: What to do with builtin functions not in libinterp subdirectory

[Daniel J Sebald]

On 03/18/2013 03:26 PM, John W. Eaton wrote:
> I'm attaching something you can play with if you like.
>
> I kept the Ffoo function definition. I don't see that it helps to have
> these built-in functions defined as member functions of a class. I think
> it is convenient that we can call them using Ffoo anywhere in Octave
> now. That's another thing you'll need to address, which is how to
> generate the list of declarations that is currently stored in
> builtin-defun-decls.h.
>
> Anyway, this code crashes Octave on startup for me because place where
> these function pointers are stored is symbol_table::fcn_table, and that
> is a static object which apparently for me is not initialized ahead of
> the first call to the builtin_function_installer constructor.
>
> One solution would be to use a singleton object for fcn_table instead of
> a static data member. That would not be too hard to do, I suppose.

OK, thanks.  I will give this a try after I stabilize what I have.  I've 
managed at least a hello-world function by using relative paths (just to 
move forward a bit) as in the code hunks below.  It isn't pretty:  It 
splits intermediate files in two build directories:

[octave]# ls ../build4/libinterp/guifcn/
libguifcn.la
[octave]# ls ../build4/libgui/guifcn/
dialog.df  guifcn_libguifcn_la-dialog.lo

but it compiles and is sort of the least amount of mods for the time being.

I fell victim to this problem for a while:

 ## FIXME -- Shouldn't the build stop if CPP fails here?

until I realized that the %.df creation was failing. Its include flags 
are not controlled the same way as when the *.cc file is compiled.  So I 
just added QT_CPPFLAGS to the command-line compile list the way that 
JAVA flags were added.

Graphic objects can't be accessed outside the GUI thread.  So I had to 
use a QMutex-QWaitCondition setup to communicate across threads.  Again, 
these are rudimentary dialogs.  More sophistication will require a lot 
of thought.  (In other words, it is a lot to expect someone to do a GSoC 
project along these lines right now until there is smooth interaction.)

I also fell victim to MOC intermediate C++ code not including the 
"config.h" directory, so _GL_INLINE_HEADER_BEGIN was not defined.  I'll 
post more details after this post.

Probably my biggest complaint about the current builtin setup is the 
amount of time it takes to rebuild after just tweaking a small file.  It 
really slows development down.  Modifying code elsewhere in the tree 
isn't too bad.

Dan


diff -r 5293cee91891 libinterp/Makefile.am
--- a/libinterp/Makefile.am     Sun Mar 17 05:12:56 2013 -0400
+++ b/libinterp/Makefile.am     Mon Mar 18 16:09:47 2013 -0500
@@ -108,6 +108,7 @@
   builtins.h \
   builtin-defun-decls.h \
   octave.h \
+  ../libgui/$(GUIFCN_INC) \
   $(OCTAVE_VALUE_INC) \
   $(PARSE_TREE_INC) \
   $(PARSER_INC) \
@@ -124,6 +125,7 @@

 DIST_SRC = \
   octave.cc \
+  ../libgui/$(GUIFCN_SRC) \
   $(OCTAVE_VALUE_SRC) \
   $(PARSE_TREE_SRC) \
   $(PARSER_SRC) \
@@ -133,6 +135,7 @@

 noinst_LTLIBRARIES =

+include ../libgui/guifcn/module.mk
 include parse-tree/module.mk
 include octave-value/module.mk
 include operators/module.mk
@@ -178,6 +181,7 @@
 include link-deps.mk

 liboctinterp_la_LIBADD = \
+  ../libgui/guifcn/libguifcn.la \
   octave-value/liboctave-value.la \
   parse-tree/libparse-tree.la \
   parse-tree/libparser.la \