[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