octave-maintainers
[Top][All Lists]
Advanced

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

Re: Locking graphics system - GUI/octave synchronization


From: Michael Goffioul
Subject: Re: Locking graphics system - GUI/octave synchronization
Date: Tue, 15 Jul 2008 22:10:33 +0200

On Tue, Jul 15, 2008 at 8:35 PM, Maciek Gajewski
<address@hidden> wrote:
> I have one small request: would it be possible to split
> graphics.cc/graphics.h(.in) int ofew smaller files? These files are huge,
> they compile like ages and are hard to work with.

In my case, graphics.cc does not compile slower or faster than any other
octave source file (at least with MSVC).

> It would be much easier to do any broad changes - like event handling, mutexes
> and uicontrols - having few smaller files.

The mutex class will be in a separate file (in liboctave), but for the rest,
I'm not sure you would gain anything (as I said, graphics.cc does not
compile slower than the rest for me). Because of the fact that most of
the graphics code is auto-generated and inlined, and because of the
inter-dependence between classes, splitting graphics.h.in would
probably mean for the user to include more files for the same end
result (at least that's my impression).

Concerning graphics.cc, for my specific case, splitting it would simply
result to increase the compilation time by a factor N (N being the
number of files after splitting). I think that what takes most of the
compilation time is the handling of templates and these headers
(like Array.h and the like) will be included anyway by all sub-files.

Maybe I'm wrong, but as the code is still in development stage,
splitting it is not really a priority for me. BTW, what do you call
"compile like ages"? For me, compiling graphics.cc takes about
5~10s.

Michael.


reply via email to

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