[Lazarus] Some syntax changes

[Mattias Gärtner]

Zitat von Hans-Peter Diettrich <DrDiettrich1 at aol.com>:

> 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