[fpc-devel] FPCUnit as a separate project from FPC?
dean.zobec at gmail.com
Tue May 22 18:10:44 CEST 2007
2007/5/22, Graeme Geldenhuys <graemeg.lists at gmail.com>:
> Hi everybody,
> Darius Blaszijk, Vincent Snijders and myself had a discussion off the
> mailing list about the possibility of moving FPCUnit out of FPC as a
> separate project. I thought it to be important that we get the
> opinions of others as well.
> In summary:
> Darius is all for it.
> Vincent is against it.
> I'm on the wire, but leaning towards the move. :-)
Dean is absolutely against it
> Some points that where raised in our discussion (please add more if I
> left some out):
> * As it stands now, FPCUnit is split between two repositories. The FPC
> one and the Lazarus one. This make it really hard to submit updates.
> The FPC one must be done first otherwise it breaks the Lazarus GUI
> TestRunner (or Console TestRunner).
FPCUnit is in fpc repository, the gui test runner is only a frontend.
The various listeners were refactored to remove dependencies from
unnecessary libraries so that fpcunit could have the minimum
requirements in terms of libraries.
E.g.the plain text and latex reports could be used avoiding
unnecessary dependencies from the XML Dom units.
All this to be able to use fpcunit in the new package system (the
vision is to be able to download a package with the system, build it
and then run automatically the tests included in the package).
This is strategic, whereas the gui stuff is of second importance imho.
Besides this I'm using the console to run the tests with plain text
output usually, and find it very practical :) .
Maybe a simplified version of Vincent's consoletestrunner could be
moved to the fpcunit package as well, moving it out of the Lazarus
> * FPC versions are a issue as the release cycles is very different for
> the FPC and Lazarus projects. Apparently the FPCUnit is broken in the
> previous release of Lazarus, due to this.
There's only some gui problem I guess.
> * Vincent likes the idea of the testing framework being part of FPC.
> One simple checkout. I think this point is moot because SubVersion
> support Externals Definitions for exactly this purpose and I think
> will actually work better than the current setup. We can link FPCUnit
> to FPC as an external link - and even link it to a specific revision
> of FPCUnit to always guarantee it pulls in a stable version of FPCUnit
> for use in FPC's test cases.
Most of us work with fresh fpc svn checkout code, I see no problem: if
a change is needed in fpc we can add it promptly in the fpc svn and
use the svn version.
> What is your thoughts on this?
Please keep it where it is now. I see no valid reason for the move.
More information about the fpc-devel