[fpc-devel] RIP NoGlobals

[Hans-Peter Diettrich]

Florian Klaempfl schrieb:

>> and prevent the use of
>> multiple back-ends in one binary.
> 
> ... which has no use.

Lazarus allows to switch targets on the fly, what currently prevents an 
incorporation of the compiler into the IDE.

For compiler development and debugging purposes it would be very nice, 
when all targets are covered in one compile.


>>> This won't change. A compiler is simply something very interwinded. Your
>>> problems with cyclic unit dependencies prove it.
>> These problems only prove poor coding conventions. When speed is favored
>> over stability and flexibility, 
> 
> Indeed, currently people complain more about FPC's speed than about it's
> stability.

Looking at "make clean all", nearly half of the time is spent in the 
cleanup, not in compiling (Windows).

I have no problems with the compilation speed, at least for repeated 
compilation during editing, where only changed files have to be recompiled.



>>> While I agree that we should refactor parts of the compiler, it should
>>> be done in an evolutionary way. Don't forget, work on 2.0 took 6 years.
>> And the results of that work are not really pleasing :-(
> 
> Really? Show me any *production* compiler which can be ported with a few
> thousand lines of code to another architecture. The FPC backend is one
> of the best written production compiler back ends I know.

Which "production" compiler back ends have you inspected?

Please note that my criticism is based on the implementation, not on the 
model - the latter is superb :-) The patchwork results in many open 
todo's, in the target units and other places.

>> It's patchwork in many parts, that destabilized the legacy code.
> 
> Well, you didn't come up with clean fixes yet either :)

See above and parallel mail - the back ends have low priority on my todo 
list. Why should I publish branches and patches, when these have no 
chance to find their way into the trunk?

DoDi