octave-maintainers
[Top][All Lists]
Advanced

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

Re: Integrating Quint into the Octave sources


From: John W. Eaton
Subject: Re: Integrating Quint into the Octave sources
Date: Mon, 18 Apr 2011 10:48:45 -0400

On 18-Apr-2011, Jacob Dawid wrote:

| navigate into the gui folder. Type
| 
| qmake
| make
| 
| That's it!

OK, I see:

  $ qmake
  $ make
  g++ -c -pipe -g3 -I/usr/include/octave-3.2.4 
-I/usr/include/octave-3.2.4/octave -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG 
-DQT_WEBKIT_LIB -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB 
-I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore 
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/qt4/QtWebKit 
-I/usr/include/qt4 -Isrc -Imoc-files -o object-files/TerminalCharacterDecoder.o 
src/TerminalCharacterDecoder.cpp
  In file included from src/TerminalCharacterDecoder.h:25,
                   from src/TerminalCharacterDecoder.cpp:23:
  src/Character.h:27:24: error: QtCore/QHash: No such file or directory

I'm building on a Debian system.  What packages do I need?

I think we need to make it a priority to properly integrate building
with the usual GNU style configure+make system.  I should be able to
configure and build out of the source tree without having to modify
any files in the source tree itself (at least from a distribution
tarball).

Also, make dist needs to be able to work correctly with the automake
rules for building distribution tarballs.

I would also like to see the code we are writing follow the coding
style of the rest of Octave.

There seem to be a number of files in the gui/src directory that have
been copied there from other projects.  Is that the usual thing to do,
or do these files exist in some libraries that we should be using
instead of copying the sources into Octave?  If some of the files in
thee gui/src directory are not maintained by us, then I would like to
separate them from the sources that we do write ourselves.  Then the
ones that are imported can be mostly left as is, so that it will be
easy to update them when the upstream version changes and it will be
clearer to me which files are the ones we maintain directly, and so
should be subject to Octave's coding standards.

jwe


reply via email to

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