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.
But you are right in so far, as the possible speedup may not be worth
such efforts around commandline parsing in general.
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...
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.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
