<p>Am 26.10.2013 02:30 schrieb "ListMember" <<a href="mailto:listmember@letterboxes.org">listmember@letterboxes.org</a>>:<br>
><br>
> On 2013-10-25 14:53, Sven Barth wrote:<br>
><br>
>> In my opinion that energy is better put into getting e.g. fcl-passrc up to date and keep it that way (so that at least each release can handle code that the compiler also accepts).<br>
><br>
><br>
> You're, of course, right.<br>
><br>
> But, never mind the question of which part of what team will maintain it (and what triggers a maintenance request, other than a long after-the-fact bug report), how do you make sure that --at any moment in time-- fcl-passrc is up-to-date?<br>

></p>
<p>The main </p>
<p>> I mean, suppose --using fcl-passrc-- we went through all the publicly available code (repositories of FPC, Lazarus, etc.) and it reported no errors, would it prove/guarantee that fcl-passrc is up-to-date?<br>
><br>
> If we could say that with enouh conjfidence, I'd gladly shift my focus to fcl-passrc.<br>
><br>
><br>
>> I already had the idea with DLLs once myself.<br>
>><br>
>> As long as the interface for exchanging options (and maybe also unit locations ;) )is kept stable or at least backwards compatible this should work. And as long as the heaps are kept seperate unloading a compiler library should also solve the problem with memory leaks... (maybe add a function to the API to get the current heap state ^^)<br>

>><br>
><br>
> Naturally <g> I know nothing about the importance of heap especially in this context or probbaly in any relevant context.<br>
><br>
> How hard would it be?<br>
><br>
><br>
> --<br>
> _______________________________________________<br>
> Lazarus mailing list<br>
> <a href="mailto:Lazarus@lists.lazarus.freepascal.org">Lazarus@lists.lazarus.freepascal.org</a><br>
> <a href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus">http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus</a><br>
</p>