On 2013-10-25 14:53, Sven Barth wrote:
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).
You're, of course, right.
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?
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?
If we could say that with enouh conjfidence, I'd gladly shift my focus
to fcl-passrc.
I already had the idea with DLLs once myself.
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 ^^)
Naturally <g> I know nothing about the importance of heap especially in
this context or probbaly in any relevant context.
How hard would it be?
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
