[fpc-devel] FPCUnit as a separate project from FPC?

[vsnijders at quicknet.nl]

----- Original Message -----
From: Joost van der Sluis <joost at cnoc.nl>
Date: Tuesday, May 22, 2007 12:55 pm
Subject: Re: [fpc-devel] FPCUnit as a separate project from FPC?

> On Tue, 2007-05-22 at 12:29 +0200, Graeme Geldenhuys wrote:
> > 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.  :-)
> 
> I think that most fpc-core developers aggree with Vincent. (On exactly
> the same reasons, but I could be wrong)
> 
> > 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).
> 
> This is the same for all of the LCL. Clearest example is maybe the 
> DB-
> components. But it holds for all of the LCL, which depends on the FCL
> and RTL. The LCL is full of version-checks to avoid problems with
> different fpc-releases.
> 
> Second there's no problem if FPCUnit is broken in svn. Those are
> _development_ versions. If people have problems with them, because 
> theydo not update enough (fpc or lazarus), that's their problem.
> 
> > * 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.
> 
> Which holds dor the complete LCL. That's why there are ifdefs all over
> the place, see above.
> 
> > * 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.
> 
> You don't want to pull in any LCL-dependencies to test the FCL or 
> otherfpc-things. So you still need to keep them separate.
> Besides, I see the graphical-features of fpcunit as a nice add-on, 
> but I
> don't use them. You can use FPCUnit as it's provided by fpc, 
> without the
> tools in Lazarus. I think there are a lot of ppl who actually do that.
> (Just like you can use the db-unit without the db-components from
> Lazarus)
> 

What I did (wrong) was that I created a TCustomApplication descendant that could be a base for all console testrunners (see lazarus\components\fpcunit\console) and made that only for fpc 2.1.1 and later in mind, because that is what I used and left that in the lazarus repository. 

Instead I should have donated that to the fpc team, so that it is clear that  it is not part of fpc 2.0.4. Now people see this in Lazarus and wonder why it doesn't work with fpc 2.0.4.

If the consoletestrunner.pas is part of fcl-fpcunit, then the runtime package is not necessary anymore and that complete directory can be removed. I could add an {$ifndef ver_2_0}  to disable the "create new console testrunner" in the fpcunitide package.

Vincent