Zitat von Hans-Peter Diettrich <[email protected]>:
Mattias Gaertner schrieb:
-it requires changes to the options, the gui, the cache.
In detail the compiler options could/should be passed directly to
the compiler, not in form of commandline options (string).
Compiling must work the same with an installed compiler and on
command line. It's hard to test all combinations, so better not use any
shortcuts.
Make all compiler options objects (or records with IDs) in the IDE,
and let the (future) compiler handle them.
There is a difference between the stored options and the real options.
Most options are stored as name, value pair. The real options are
computed on demand. The compiler only needs the real options. The
computed options are concatenated as command line string.
Theoretically it can produce another output, but the compiler has
everything to parse command line options, the speedup is not
measurable. I think we should not add extra formats without need.
But you are right in so far, as the possible speedup may not be
worth such efforts around commandline parsing in general.
I have never seen the command line handling in the profiler.
Let's first concentrate on what really takes time: file access.
Also the time consuming unit search could be reduced or
eliminated, when the IDE and compiler share the same
file/directory cache.
Yes.
Although I guess they need different structures. But the
compiler could load files/directories from the IDE caches. That
should speed up a lot, especially under windows.
We only have to agree about a common base class...
Some kind of virtual file system is also needed for the version
control addons.
And not to forget the handling of compiler messages, that can go
immediately into the IDE messages window.
They should not go "immediately". They need to be categorized,
filtered, improved and buffered. And when code changes the output is
adapted.
They can be intercepted in the Message() subroutine(s). This part
(verbose.pas...) deserves refactoring anyhow, in a threaded
compiler. Then every unit-parser thread must maintain its own
message queue, else the resulting log would be garbled. But see
below...
Do you already have more concrete ideas, what in detail should be
encapsulated, WRT later IDE integration of the compiler?
I don't have concrete ideas yet.
I have a long list of goals, including translation,
multithreading and different compilers.
I'm not sure whether parser threads and parallel compilation really
will speed up the compiler. But a compiler in a background thread
would be nice for the IDE.
The goal is that the IDE should not slow down, even if compiling with -va.
I'm not sure how much parallel compilation speed up things in daily
work, but I see some potential. Using the IDE file/directory caches
will probably help more in daily work.
Mattias
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
