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 Swensen
Subject: Re: Integrating Quint into the Octave sources
Date: Mon, 18 Apr 2011 10:51:03 -0400

On Apr 18, 2011, at 10:48 AM, John W. Eaton wrote:

> 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

Many of the files were "ripped out" of the Konsole sources and modified to make 
them KDE-free.  Maybe we should separate those from the rest of the sources, as 
it would be a ton of work to make them follow the coding standard and would 
also make it harder to incorporate bugfixes from the KDE sources.

John Swensen

reply via email to

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