Sorry, pressed Send by accident... -.* Am 26.10.2013 02:30 schrieb "ListMember" <[email protected]>: > > 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. >
The main tests for what FPC supports and what not is for one compiling (or in this context at least "parsing") the compiler's source, the RTL and the packages. Additionally there are the tests which should either succeed or dail to compile/run (and when a new feature is added at least one test is added). So in my opinion the ability to correctly parse compiler, RTL and packages sources plus correctly parsing all tests that should compile and failing all tests that should fail would be enough in my opinion. The main maintenance would be by the FPC team, but patches are welcome and if someone (e.g. you) "proves worthy" he can get SVN write to the fcl-passrc directory. > >> 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? As non-shared heap is the default, this would be no problem ^^ Regards, Sven
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
