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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel