On 5-Aug-2012, Michael Goffioul wrote:
| With the change
|
| http://hg.savannah.gnu.org/hgweb/octave/rev/3d7a7ae53bbf
|
| building the GUI should be pretty well integrated with the octave build system.
| It adds support for resource files compilation and for the "dist" target.
Thanks. I checked in a few more improvements here:
http://hg.savannah.gnu.org/hgweb/octave/rev/3735a0e783cb
Now we don't try run qmake or look for moc, uic, or rcc unless qmake
is available. Running make from the top-level directory will also
build the GUI, so you don't have to cd to the gui directory and run
make separately. I also defined a HAVE_QT flag in config.h, but it's
not used yet.
Thanks, just a couple of questions/comments:
1) why didn't you remove the line "SUBDIRS += gui" in top-level Makefile.am? it seems useless with the @GUIDIR@ replacement; note that I didn't do it that way, because I wasn't sure whether it would be picked up by the "dist" target even if @GUIDIR@ is set to an empty value
2) thanks for the $(@D) trick, I wasn't aware of it
Note that if you don't have Octave installed, Octave will not know
where to find the core .m files. It will be searching for them in
the installation directory tree, not the source tree.
Indeed, that's the remaining problem.
To fix that, we
need a "run-octave" script for the GUI. But before doing that, I
think we should decide how we want to integrate the "octave-gui" main
program and the current "octave" main program. I started working on
the attached changes to do that, so that if we are building the GUI,
then the "octave-gui" main program can be THE Octave program. It's
not finished yet, as we need an option for "--disable-gui" and there
are some things I'm not sure about, like what should happen for things
like
octave --eval "foo"
Without the --persist option, should a command like this start the GUI
and execute the command in the terminal window, then immediately close
the GUI? Or should it skip starting the GUI? With --persist, it
seems obvious that it should start the GUI and evaluate the command in
the GUI terminal window. What if the commands to be evaluated perform
some operation that requires the GUI environment? Should we have a
--force-gui option for that case?
I don't really have an answer to that, but there's one thing I think about when considering merging the console and GUI executables. Qt libraries are quite large and loading them takes time and memory (especially on low-end hardware). By merging both executables, you force the load of Qt libraries, even if you don't use them in the end. I'm not sure there's a perfect solution to that, but I expect complaints form people using octave, but not interested in the GUI. So maybe we should keep a CLI-only version around anyway.
Michael.