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. :-)

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).

* 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.

* 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.

* FPCUnit could move to the same repository as the other 3rdParty FPC tools like LNet. I can't remember the exact SubVersion URL now. It will still be close to FPC, just not live in the same repository.

What is your thoughts on this?

I think that most fpc-core developers aggree with Vincent. (On exactly the same reasons, but I could be wrong)

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 they do 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.

You don't want to pull in any LCL-dependencies to test the FCL or other fpc-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)

* FPCUnit could move to the same repository as the other 3rdParty FPC tools like LNet. I can't remember the exact SubVersion URL now. It will still be close to FPC, just not live in the same repository.

What will become a real maintenance-nightmare, is if we split everything up in it's own repository. Release-management is an horror already as it is now...

And while this looks developer-friendly at start, it's user-unfriendly: 'Ah, you want to use Lazarus! Great, first you have to download+install fpc, and thereafter Lazarus. But if you want to use DB-controls, install the DB-controls from svn-XXX. If you need tests, install the FPCUnit- package, which you can find here ... . etc. etc. Maybe the new packaging-system can help here, though....

Joost

Joost van der Sluis wrote

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.

This is true and I see you point.

You don't want to pull in any LCL-dependencies to test the FCL or other fpc-things. So you still need to keep them separate.

You don't have to pull in any LCL-dependencies. If the FPCUnit project is structured correctly, the core FPCUnit would still be a separate directory from the GUI or Console Runners. The externals link from FPC could pull in only the FPCUnit core (no GUI stuff).

Thanks for you other comments... You make some valid points.

----- Original Message -----

This is not quite correct. The only part which should be in Lazarus is the GUI stuff. The console testrunner can perfectly be integrated in FPC. (as stated by Vincent)

* 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.

This is a non-argument, it goes for all units in FPC which are used in Lazarus...

The FPC automated testsuite will move towards FPCunit. We cannot do this if fpcunit is a separate project, because then an external influence could break the whole testsuite. You'll understand that this is not acceptable. If it is in FPC svn, we control at least all what we need ourselves.

So from the FPC point of view this proposal is a big no-no.

What concerns LNet, it was moved out only because it was not considered stable enough by the author. As soon as it is stable enough, it moves back in. Our packaging tool will depend on it. So you cannot really use this as an argument for moving.

The best that can be done is move the console runner to the FCL, and leave only the GUI part in Lazarus.

Michael.

I agree about the console testrunner. That should move to FPC. My argument for submitting updates still hold. What if I submit something in FPCUnit (core) that would break the GUI TestRunner. I have to submit the FPCUnit core changes first. Wait till it's been applied, then submit the Lazarus updates. While the Lazarus updates have not been applied the GUI TestRunner is broken. This would have happened again a few weeks ago, but my patch still hasn't been applied in either project. :-(

The best that can be done is move the console runner to the FCL, and leave only the GUI part in Lazarus.

This must definitely be done! I can live with the GUI Runner being broken, but Console Runner not.

Please note:
I'm just raising some questions Darius had. I'm still happily sitting on the fence. :-)
I can see positive and negative things either way.

If it helps, I see no problem to give Dean write access to the FPC repository. I guess the same applies for lazarus.

2007/5/22, Graeme Geldenhuys :

Dean is absolutely against it

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 repository.

* 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.

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.

Regards,
Dean

Graeme Geldenhuys pravi:

Radical changes in FPCUnit core are rare, and if they happen they would reside in the latest svn trunk. The lag you mention about the Lazarus svn update was a day or two usually, no big problem.

While the Lazarus updates have not been applied the GUI TestRunner is broken. This would have happened again a few weeks ago, but my patch still hasn't been applied in either project. :-(

I'll take a look at them this evening.

No problem, I'm sure that the best solution is to keep fpcunit in the fcl, I'll have more time to dedicate to the project this summer and quite sure that all the possible problems will be resolved as usual, with no need to complicate things. Hope we'll achieve together some big improvements. Big thanks to you and Darius for the discussion, it's needed sometimes.

Regards,
Dean

Florian Klaempfl pravi:

If it helps, I see no problem to give Dean write access to the FPC repository. I guess the same applies for lazarus.

Thank you for the offer. I think it's not necessary for now, I get along very well with MvC's mentorship and like to discuss with the core team every single step I take, a day or two in the svn update won't make any difference I guess.

Dean

I can't remember the details - the patch was submitted a while back. Basically running the GUI, it always writes to the console as well, which I think is wrong. So while the tests run, the console gets filled up as well as the XML test results tab.

I'm a GUI TestRunner fan - I just love seeing that Green Bar! The console testrunner doesn't give me the same pleasure... ;-)

No problem, I'm sure that the best solution is to keep fpcunit in the fcl, I'll have more time to dedicate to the project this summer and

Well, I guess that settles it then. FPCUnit stays where it is!

Well, I guess that settles it then. FPCUnit stays where it is!

After reading all the comments and remarks from today's thread, I'm also convinced now that FPCUnit can stay in FPC, provided the Lazarus console test runner code is moved to FPC as much as possible (apart from the IDE package). This way breakage seems less likely and I can add it as external to my SVN. Thanks all for giving constructive criticism, I think I saw more problems than solutions for a while, but it's all clear to me now.

Darius