[fpc-devel] RIP NoGlobals
DrDiettrich1 at aol.com
Thu Sep 30 11:29:40 CEST 2010
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
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?
More information about the fpc-devel