[fpc-devel] RIP NoGlobals

Florian Klaempfl florian at freepascal.org
Thu Sep 30 11:44:30 CEST 2010


Am 30.09.2010 11:29, schrieb 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.

Define a proper compiler API and load the compiler as shared lib. This
allows also to work with different compiler versions in the future when
the API is stabilized.

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

make fullcycle does this too.

> 
> Which "production" compiler back ends have you inspected?

GCC, Watcom, LLVM.

>>>> 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).

rm build-stamp.*
make all
is what I usually do :)

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

Me neither, but other people, see recent discussions.

> 
> 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?

Well, to give them a chance, it's important to discuss them as early as
possible.



More information about the fpc-devel mailing list