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

That's easy:

function Compile(const filename, options: string; caches: TCaches): 
TMessageList;

What else are you missing?


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

At a very high cost :-(


>> Which "production" compiler back ends have you inspected?
> 
> GCC, Watcom, LLVM.

Which of these claims for "best performance", in favor of "best 
portability"?


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

That's problematic. While the goals are quite clear, the steps to 
achieve the goals are inpredictable in most cases - everything depends 
on problems encountered during an implementation attempt. A discussion 
of such problems requires some familiarity with the details, and with 
the consequences of possible solutions. Too bad when obvious 
consequences are not mentioned just-in-time, because some guru has no 
time for following the discussion(s).


I'd appreciate better ways for providing material for discusson, than 
branches in the SVN repository. Such branches are hard to remove, if 
ever, and restarting with a preceding version, when a dead end was hit, 
also is problematic. Currently I try to provide some patches, based on 
SVN patches, but developed using a Git repo. I found no solution for the 
different revisions, that are required as the base of both SVN and Git 
patches - anybody?

Another solution could be a (non-tracking) Git repo on some public 
server, where experimental branches can be created and removed freely. 
Patches for inclusion into the SVN repo can be created from a Git repo, 
when both share the same working copy. Thanks to Graeme for mentioning 
this trick :-)

DoDi