Thread: RE: [Cppunit-devel] 1.6.0 is released!
Brought to you by:
blep
From: Bastiaan B. <Bas...@li...> - 2001-09-24 07:30:56
|
Hi, Congratulations on the 1.6.0 release!=20 Steve, do you want me to do a FreshMeat announcement?=20 Regards, Bastiaan =20 |
From: Summerwill, B. <BSu...@eu...> - 2001-09-24 08:29:40
|
Excellent news! I'll be grabbing a copy today. Cheers, Bob -----Original Message----- From: Steve M. Robbins [mailto:ste...@vi...] Sent: 24 September 2001 05:23 To: CppUnit Development Subject: [Cppunit-devel] 1.6.0 is released! I'm happy to report that version 1.6.0 is now available on the SourceForge web site. The only significant change from the last snapshot is a last-minute bugfix from Baptiste. (The other changes were to doc files.) The CVS tree is synched up with the release version, and tagged (tag REL_1_6_0). My immediate plans are to wait and see what bug reports come in. I am prepared to make a 1.6.1 release as soon as necessary, and generally I plan to keep making 1.6.x releases as necessary to fix bugs. In the meanwhile, we should kick around ideas for 1.8.0. I generally favour the "release early, release often" policy. How about the rest of you? If we go that route though, we need to be aggressive in limiting what changes will be made for 1.8. Let's hear ideas! -Steve P.S. I haven't yet made a branch in the CVS tree, so let's hold off on non-bugfix changes until a branch is made. -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants _______________________________________________ Cppunit-devel mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cppunit-devel |
From: Steve M. R. <ste...@vi...> - 2001-09-24 11:31:18
|
On Mon, Sep 24, 2001 at 09:27:00AM +0200, Bastiaan Bakker wrote: > Congratulations on the 1.6.0 release! Thanks to you and to Baptiste! > Steve, do you want me to do a FreshMeat announcement? Yes, thanks! On a similar note: does anyone here monitor the source forge web fora and answer questions? Having a long history with usenet and mailing lists, I find the web-based messaging exceedingly clumsy, so I don't use it. However, others do use it, and it would be nice for them to have their questions answered in a timely fashion. -S P.S. I found the first bug in cppunit-docs-1.6.0.tar.gz about 10 minutes after making it. The "cookbook.html" file is missing. -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |
From: Baptiste L. <gai...@fr...> - 2001-09-24 13:15:06
|
Quoting "Steve M. Robbins" <ste...@vi...>: > > On Mon, Sep 24, 2001 at 09:27:00AM +0200, Bastiaan Bakker wrote: > > > Congratulations on the 1.6.0 release! > > Thanks to you and to Baptiste! > > > Steve, do you want me to do a FreshMeat announcement? > > Yes, thanks! I also posted the news on the XP mailing list (ext...@ya..., warning: high traffic). > > > On a similar note: does anyone here monitor the source forge web fora > and answer questions? Having a long history with usenet and mailing > lists, I find the web-based messaging exceedingly clumsy, so I don't > use it. However, others do use it, and it would be nice for them to > have their questions answered in a timely fashion. I do, but since I have a monthly time budget for internet connection, the response are usually off by a few days, if I don't forget completly about them (for some strange reason, I can't login on SF anymore from work, I just get back to the login page without any error message!). I do agree that it is very clumsy in its use: you get a copy of the message, but can't answer. > > -S > P.S. I found the first bug in cppunit-docs-1.6.0.tar.gz about 10 > minutes after making it. The "cookbook.html" file is missing. Hey, talking about doc, is there a place where we could put up the WIN32 FAQ (got again a FAQ #1 question, and the cockbook will lead to FAQ #1 question (crash if RTTI is not enabled)). Another point, I'd like to be able to generate documentation with doxygen on WIN32. To do so I would need to have a version Doxyfile.in where "macro" stuff have been replaced. Is there a way to do that in an automatized fashion ? Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Language: English, French |
From: Steve M. R. <ste...@vi...> - 2001-09-24 13:49:25
|
On Mon, Sep 24, 2001 at 03:15:01PM +0200, Baptiste Lepilleur wrote: > Hey, talking about doc, is there a place where we could put up the WIN32 FAQ > (got again a FAQ #1 question, and the cockbook will lead to FAQ #1 question > (crash if RTTI is not enabled)). The only FAQ of which I am aware is the three questions at the bottom of INSTALL-WIN32.txt :-) A more visible FAQ would be a great addition. If you wish to start one, my suggestion is to put it in the doc/ directory of the sources. I can make arrangements for it to get automatically updated to the web page cppunit.sf.net every so often. > Another point, I'd like to be able to generate documentation with doxygen on > WIN32. To do so I would need to have a version Doxyfile.in where "macro" stuff > have been replaced. Is there a way to do that in an automatized fashion ? Baptiste, maybe it is time to bite the bullet and join us in autoconf-land! ;-) Seriously, there has been work to generate Visual C++ project files automatically using a configure script. I'm not sure how viable it is at the moment, but I'm certainly willing to do everything necessary to support you, short of actual testing (I have no MSwin machine). The last message I saw about this is at http://mail.gnu.org/pipermail/automake/2001-August/009531.html if you wish to follow it up. -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |
From: Baptiste L. <bl...@cl...> - 2001-09-24 21:35:55
|
----- Original Message ----- From: "Steve M. Robbins" <ste...@vi...> To: "CppUnit Development" <cpp...@li...> Sent: Monday, September 24, 2001 3:49 PM Subject: Re: [Cppunit-devel] 1.6.0 is released! > On Mon, Sep 24, 2001 at 03:15:01PM +0200, Baptiste Lepilleur wrote: > > > Hey, talking about doc, is there a place where we could put up the WIN32 FAQ > > (got again a FAQ #1 question, and the cockbook will lead to FAQ #1 question > > (crash if RTTI is not enabled)). > > The only FAQ of which I am aware is the three questions at the bottom of > INSTALL-WIN32.txt :-) > > A more visible FAQ would be a great addition. > > If you wish to start one, my suggestion is to put it in the doc/ > directory of the sources. I can make arrangements for it to get > automatically updated to the web page cppunit.sf.net every so often. HTML format or text, or ... ? > > Another point, I'd like to be able to generate documentation with doxygen on > > WIN32. To do so I would need to have a version Doxyfile.in where "macro" stuff > > have been replaced. Is there a way to do that in an automatized fashion ? > > Baptiste, maybe it is time to bite the bullet and join us in autoconf-land! ;-) Well, If you were to give me the @@topdir@@ & co value (or semantic), it could probably be automatised with a simple search and replace (a slighty easier solution ;-) ) > > Seriously, there has been work to generate Visual C++ project files > automatically using a configure script. I'm not sure how viable it is > at the moment, but I'm certainly willing to do everything necessary to > support you, short of actual testing (I have no MSwin machine). The > last message I saw about this is at > http://mail.gnu.org/pipermail/automake/2001-August/009531.html > if you wish to follow it up. I'll try to give it a look. I tried to use TMAKE (from Qt, a free perl tool to generate Makefile using template) to generate project file from the project definition instead of a Makefile for Qt TestRunner, but it conveniently forgot the Enable RTTI and Enable Exception support flag... May be qmake fixed (Qt 3.0) that but it still isn't available on Windows... Generating Makefile work file on the other hand. Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Author of The Text Reformatter, a tool for fanfiction readers and writers. Language: English, French (Well, I'm French). |
From: Steve M. R. <ste...@vi...> - 2001-09-25 06:25:41
|
Hi Baptiste, I'm saving all the 1.8 feature ideas you have been posting until I have some time to think about them. I'll try here to reply to your other messages. On Mon, Sep 24, 2001 at 11:10:42PM +0200, Baptiste Lepilleur wrote: > > If you wish to start one, my suggestion is to put it in the doc/ > > directory of the sources. I can make arrangements for it to get > > automatically updated to the web page cppunit.sf.net every so often. > > HTML format or text, or ... ? Your choice. HTML has the advantage of hyperlinks, should one so desire. I find text quite a bit easier to edit, however, so HTML may put me off editing the FAQ... > > > Another point, I'd like to be able to generate documentation with > doxygen on > > > WIN32. To do so I would need to have a version Doxyfile.in where "macro" > stuff > > > have been replaced. Is there a way to do that in an automatized fashion > ? > > > > Baptiste, maybe it is time to bite the bullet and join us in > autoconf-land! ;-) > > Well, If you were to give me the @@topdir@@ & co value (or semantic), it > could probably be automatised with a simple search and replace (a slighty > easier solution ;-) ) In the long run, I think this is not so easy, to be honest. But MS ain't my problem ... :-) You want to replace @top_srcdir@ with the path to the top of the source directory, @srcdir@ is the path to the current source dir, etc. Look in Makefile.in for clues to the other replacements. On Mon, Sep 24, 2001 at 09:47:22PM +0200, Baptiste Lepilleur wrote: > > The CVS tree is synched up with the release version, and tagged (tag > > REL_1_6_0). My immediate plans are to wait and see what bug reports > > come in. I am prepared to make a 1.6.1 release as soon as necessary, > > and generally I plan to keep making 1.6.x releases as necessary to fix > > bugs. > > Well, there are bugs in cppunittest/TestCallerTest (as well as a few > memory leaks I did not spot last time), is does not check correctly the > expected exception stuff. Should that go in 1.6.1 or 1.8.0 (with the > exception enhancement I proposed in another mail)? If there is a bug in 1.6.0 that you can fix without major surgery, then yes, it should go into 1.6.1. The 1.6.x series should fix all bugs in 1.6.0 that are reasonable to fix. > > In the meanwhile, we should kick around ideas for 1.8.0. I generally > > favour the "release early, release often" policy. How about the rest > > of you? If we go that route though, we need to be aggressive in > > limiting what changes will be made for 1.8. Let's hear ideas! > > What is your definition of often ? once a month, biweekly, weekly ? For bugfix releases, I'm prepared to go for once a week or more, if necessary. For new-feature releases, the schedule will depend on what we want to get done, and how much free time one has, and all the rest of it. I don't have a fixed schedule in mind, but something on the order of a month or two is in the right ballpark, I think. > As time go, we should strengthen our test suite. Whenever a bug is > found, we should try to write a test for it. I already did it for > the TestCaller thingy. Great! Yes, test cases for cppunit are good things. They should also go into the bugfix releases, IMHO. On Mon, Sep 24, 2001 at 09:05:48PM +0200, Baptiste Lepilleur wrote: > Yesterday I found a bug in test caller. When an expected exception > wasn't caught, it did: > throw new Exception(...) instead of > throw Exception(...). > > I went down to the test suite to see why it was not detected. Result: > forgot to put a test case for that one. I'm in the process of correcting > this, but there is no way I can safely distinguish if "new Exception()" or > "Exception()" was thrown. There can only be distinguished by the message. Is this for the test suite or for the main code? If the former, is it possible to simply use catch blocks for both "Exception" and "Exception*" types? -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |
From: Baptiste L. <gai...@fr...> - 2001-09-25 15:54:07
|
Quoting "Steve M. Robbins" <ste...@vi...>: > Salut, B-L, Tisba for short ;-). Learning French ? > On Tue, Sep 25, 2001 at 12:32:21PM +0200, Baptiste Lepilleur wrote: > > Quoting "Steve M. Robbins" <ste...@vi...>: > > > > [...] > > > > HTML format or text, or ... ? > > > > > > Your choice. HTML has the advantage of hyperlinks, should one so > > > desire. I find text quite a bit easier to edit, however, so HTML > may > > > put me off editing the FAQ... > > So let's start with text. Would XML (with XSL to generate the html) > be > > suitable for you ? > > I wouldn't know what to do with XML, either :-/ > > I usually stay a little back of the "new technology" curve --- that > way I can avoid travelling down all the dead-ends ;-) Well, with the appropriate XSL script (to generate the HTML), we could get automatically have a TOC generated from each question. That's what I don't like with HTML is that you have to manually maintain the TOC... Basicaly, the XML would be a subset of HTML and would be processed into HTML (that's heavy tools, but I think it would be quite interesting to do). > From my point of view, I prefer text. If we find ourselves wanting > fancy things, like links, then we can move to straight HTML, or to > something that can be processed into HTML. We could use Doxygen, > for example, as done in doc/other_documentation.dox. Doxygen has > an easy way to make lists, I believe. And it would be *very* easy > to hyperlink both to and from the CppUnit class documentation, so > that might be the best option. Yes, linking to the doc would be interesting. Can Doxygen generate a TOC ? [...] > If you build *in* the source tree, then builddir == srcdir, so > the Makefile variables are simpler: > > top_srcdir = .. > srcdir = . > top_builddir = .. I'll try to come up with something to generate the doc (sadly, we don't have a standard search and replace tools...) > > How do we go reporting fix into the 1.8.0 branch ? > > Well, since there is no branch done yet, everything on the "main" > trunk will appear in both the 1.6.1 and 1.8.0 release. So please > do commit bugfixes onto the CVS tree. > > Once a branch is made, then the procedure is: checkout the 1.6 branch, > make the change, commit it. Then check out the main branch and merge > in the change just made on the 1.6 branch. This is a mildly more > difficult procedure, so I am delaying making a 1.6 branch in order > that we can continue to use the simpler procedure. > > We can delay a 1.6 branch until we need to make 1.8-only changes to > CVS. I thought we'd give it a week or so, until the bugfixes die > down. What do you think? Well, I already have some features (CPPUNIT_TEST_EXCEPTION) I would like to add (I would target 1.8.0 for the end of next week. Expected exception and named suite registration only would be worth it). How about: - continue reporting bug fix to branch 1.6 - add feature to branch 1.8 - each time a release of branch 1.6 is made, merge the change since the last release on the branch ? or - merge change that occured on branch 1.6 since branch 1.8 creation to branch 1.8 ? => instead of merging each time we update 1.6, we do it only once per bug fix release (or we could even postpone until 1.8 release to integrate bugfix) Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Language: English, French |
From: Steve M. R. <ste...@vi...> - 2001-09-27 05:44:15
|
On Tue, Sep 25, 2001 at 05:54:02PM +0200, Baptiste Lepilleur wrote: > Quoting "Steve M. Robbins" <ste...@vi...>: > > From my point of view, I prefer text. If we find ourselves wanting > > fancy things, like links, then we can move to straight HTML, or to > > something that can be processed into HTML. We could use Doxygen, > > for example, as done in doc/other_documentation.dox. Doxygen has > > an easy way to make lists, I believe. And it would be *very* easy > > to hyperlink both to and from the CppUnit class documentation, so > > that might be the best option. > > Yes, linking to the doc would be interesting. Can Doxygen generate a TOC ? Mmmm. If it does, I don't know how to do that. You can, however, make "groups" of bits of documentation, and you automatically get a "group" page. That might be good enough. But, anyway, we have only three questions at this point. Let's just do _something_ now and figure out the niceties if it gets to be a burden. > > > How do we go reporting fix into the 1.8.0 branch ? > > > > Well, since there is no branch done yet, everything on the "main" > > trunk will appear in both the 1.6.1 and 1.8.0 release. So please > > do commit bugfixes onto the CVS tree. > > > > Once a branch is made, then the procedure is: checkout the 1.6 branch, > > make the change, commit it. Then check out the main branch and merge > > in the change just made on the 1.6 branch. This is a mildly more > > difficult procedure, so I am delaying making a 1.6 branch in order > > that we can continue to use the simpler procedure. > > > > We can delay a 1.6 branch until we need to make 1.8-only changes to > > CVS. I thought we'd give it a week or so, until the bugfixes die > > down. What do you think? > > Well, I already have some features (CPPUNIT_TEST_EXCEPTION) I would like to > add (I would target 1.8.0 for the end of next week. Expected exception and > named suite registration only would be worth it). Well, so far, we aren't exactly inundated with bug reports. So making the change at the end of next week is probably fine. At any rate, ONCE the branch is made, the idea is to merge 1.6.x bugfix changes to the main trunk (if applicable) as you do them. Any delay of the merge just makes it more complicated. -Steve P.S. I guess the lack of bug reports is good, unless it means that nobody is using CppUnit. We are getting a bunch of traffic though: check out the "stats" page if you haven't already done so. -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |
From: Baptiste L. <gai...@fr...> - 2001-09-27 12:59:09
|
Quoting "Steve M. Robbins" <ste...@vi...>: > On Tue, Sep 25, 2001 at 05:54:02PM +0200, Baptiste Lepilleur wrote: > > Quoting "Steve M. Robbins" <ste...@vi...>: > > Yes, linking to the doc would be interesting. Can Doxygen generate a > TOC ? > > Mmmm. If it does, I don't know how to do that. > You can, however, make "groups" of bits of documentation, and > you automatically get a "group" page. That might be good enough. > > But, anyway, we have only three questions at this point. Let's just > do _something_ now and figure out the niceties if it gets to be a > burden. > > > > > > How do we go reporting fix into the 1.8.0 branch ? > > > > > > Well, since there is no branch done yet, everything on the "main" > > > trunk will appear in both the 1.6.1 and 1.8.0 release. So please > > > do commit bugfixes onto the CVS tree. > > > > > > Once a branch is made, then the procedure is: checkout the 1.6 > branch, > > > make the change, commit it. Then check out the main branch and > merge > > > in the change just made on the 1.6 branch. This is a mildly more > > > difficult procedure, so I am delaying making a 1.6 branch in order > > > that we can continue to use the simpler procedure. > > > > > > We can delay a 1.6 branch until we need to make 1.8-only changes > to > > > CVS. I thought we'd give it a week or so, until the bugfixes die > > > down. What do you think? > > > > Well, I already have some features (CPPUNIT_TEST_EXCEPTION) I would > > like to > > add (I would target 1.8.0 for the end of next week. Expected exception > and > > named suite registration only would be worth it). > > Well, so far, we aren't exactly inundated with bug reports. So making > the change at the end of next week is probably fine. > > At any rate, ONCE the branch is made, the idea is to merge 1.6.x > bugfix changes to the main trunk (if applicable) as you do them. > Any delay of the merge just makes it more complicated. Well, I was thinking about a slighlty tighter time schedule :-) - have the branch made this week-end, and - release 1.8.0 by the end of next week-end... Given that scope, the following feature would be possible: 1) CPPUNIT_TEST_EXCEPTION( method, ExceptionType) 2) CPPUNIT_TEST_FAIL( method ) 3) add a flag to TestFailure distinguishing error/failure, retain only one collection to store result (see other mail) 4) CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( TestFixtureType, SuiteName ) : register the fixture's suite in a suite of the specified name. Given the low rate of feedback on the other topics, I can't see them being done "quickly". So I'd rather have a quick release with those features which are simple but very useful. I'm also thinking of adding: CPPUNIT_FAIL( message ) as a shortcut for CPPUNIT_ASSERT_MESSAGE( message, false ), which is often use to indicate unexpected path (exception...) > > -Steve > > P.S. I guess the lack of bug reports is good, unless it means that > nobody is using CppUnit. We are getting a bunch of traffic though: > check out the "stats" page if you haven't already done so. Indeed, it's been quite a climb... By the way, has xprogramming.org been contacted, the page haven't been updated ? Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Language: English, French |
From: Steve M. R. <ste...@vi...> - 2001-09-29 18:28:36
|
On Thu, Sep 27, 2001 at 02:59:04PM +0200, Baptiste Lepilleur wrote: > Quoting "Steve M. Robbins" <ste...@vi...>: > > Well, so far, we aren't exactly inundated with bug reports. So making > > the change at the end of next week is probably fine. > > > > At any rate, ONCE the branch is made, the idea is to merge 1.6.x > > bugfix changes to the main trunk (if applicable) as you do them. > > Any delay of the merge just makes it more complicated. > > Well, I was thinking about a slighlty tighter time schedule :-) > - have the branch made this week-end, and > - release 1.8.0 by the end of next week-end... Ah, I had originally misunderstood your timetable. OK, I have time this weekend to do 1.6.1, and then I'll make the branch at that point. Deal? So the question becomes: what can we reasonably include in 1.6.1? The changes I'd like to make are the following 1. Fix the doc file to include cookbook.html. 2. Eliminate the repeated includes pointed out by Bob S. 3. Include the (non-OSX) mac config. 4. Include an FAQ available both in the sources and via the web. 5. Updated docs, especially the intro/cookbook. I can certainly do #1 and #2 myself. For #3 to make it in, someone (Duane?) will have to supply the relevant preprocessor symbols to use. Since Baptiste has already expressed interest in the FAQ, I'm happy to leave that to him should he wish it; otherwise I'll throw something together at the last minute. To aid the FAQ compiler, it would be helpful to send in candidate questions and answers. Perhaps those of you who just joined us recall one or two large stumbling blocks? Or those of you reading the user- and help- forums see questions coming up over and over? Similarly, corrections and additions to other bits of docs would be greatly appreciated! In particular, the intro page (cppunit.sf.net) cookbook need work. Learning to use CppUnit was quite troublesome in my experience, so this is one area that should get extra attention, I feel. Are there other items to include in 1.6.1 that can be done today or tomorrow (especially on the non-unix side)? -Steve P.S. Don't worry about the short deadlines. We can make 1.6.2 at any time. > By the way, has xprogramming.org been contacted, the page haven't been > updated ? Not by me. I'm only handling the SF release process (and I'm going to do the next Debian release, too). Baastien said he did a freshmeat announcement. I don't know of any other channels. I'd suggest: if you know of a community of potential interest then make the announcement and let us on cppunit-devel know. -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |
From: Baptiste L. <bl...@cl...> - 2001-09-29 20:40:49
|
----- Original Message ----- From: "Steve M. Robbins" <ste...@vi...> To: "Cpp Unit Develpment Mailing List" <cpp...@li...> Sent: Saturday, September 29, 2001 8:28 PM Subject: [Cppunit-devel] 1.6.1 changes > On Thu, Sep 27, 2001 at 02:59:04PM +0200, Baptiste Lepilleur wrote: > > Quoting "Steve M. Robbins" <ste...@vi...>: > > > > Well, so far, we aren't exactly inundated with bug reports. So making > > > the change at the end of next week is probably fine. > > > > > > At any rate, ONCE the branch is made, the idea is to merge 1.6.x > > > bugfix changes to the main trunk (if applicable) as you do them. > > > Any delay of the merge just makes it more complicated. > > > > Well, I was thinking about a slighlty tighter time schedule :-) > > - have the branch made this week-end, and > > - release 1.8.0 by the end of next week-end... > > Ah, I had originally misunderstood your timetable. > > OK, I have time this weekend to do 1.6.1, and then I'll make the branch > at that point. Deal? Sound good to me. > So the question becomes: what can we reasonably include in 1.6.1? > The changes I'd like to make are the following > > 1. Fix the doc file to include cookbook.html. > 2. Eliminate the repeated includes pointed out by Bob S. > 3. Include the (non-OSX) mac config. > 4. Include an FAQ available both in the sources and via the web. > 5. Updated docs, especially the intro/cookbook. I also comitted a little while ago the TestCallerTest fix (nothing major). > I can certainly do #1 and #2 myself. For #3 to make it in, someone > (Duane?) will have to supply the relevant preprocessor symbols to > use. Since Baptiste has already expressed interest in the FAQ, I'm > happy to leave that to him should he wish it; otherwise I'll throw > something together at the last minute. Wouldn't mean to. Though how would you organize the FAQ ? I can think of 3 sections should come out: - Windows specifics Well, we already have 3 questions compiled from FAQ on the forum. More are welcome. - Unix specifics (would this includes Mac OS X?) I'm the dumb boy there here. How to I build the examples, where do I found the executable of the build samples... - Generic Where is the XML output ? ;-) > To aid the FAQ compiler, it would be helpful to send in candidate > questions and answers. Perhaps those of you who just joined us > recall one or two large stumbling blocks? Or those of you reading > the user- and help- forums see questions coming up over and over? > > Similarly, corrections and additions to other bits of docs would be > greatly appreciated! In particular, the intro page (cppunit.sf.net) > cookbook need work. Learning to use CppUnit was quite troublesome in > my experience, so this is one area that should get extra attention, I > feel. I skimmed through the cookbook and I noticed that the macros are never evoked. I think that the macros are actually the fastest way to get started with CppUnit (especially on VC++ where you can have VC++ macro or add-ins generating most of the code for you). That's how I'm introducing CppUnit at work. I present a Fixture, and show how to add tests and what are the macro available to write assertions. How a suite is created for the fixture and where you can find it in the TestRunner. That way you can start using the framework without having to understand it. Face it, most of the guys don't really care how CppUnit works. They just want it to make their life easier. They might want to start understanding the whole thing when they want to write attipical test (functionnal test), or reach the limit of CppUnit and want to enhance it... Of course, I don't think that "for tomorow TODO". Oh, by the way, I have those nifty Workspace Whiz template that allow the owner of that add-ins to create a new test case class and had it to the project in a few mouse click. Where should I put it in the CppUnit dist ? I was thinking of contrib/msvc/. > Are there other items to include in 1.6.1 that can be done today or > tomorrow (especially on the non-unix side)? Well, I actually got a bug report (somewhat MFC don't open the right dialog when browsing the unit test). I'll try to reproduce it before attempting solving it. Since it's MFC black magic and I'm not really an expert in that area, I don't expect a quick resolution. I'll have to reproduce the bug first. > > -Steve > > P.S. Don't worry about the short deadlines. We can make 1.6.2 at any > time. > > > > By the way, has xprogramming.org been contacted, the page haven't been > > updated ? > > Not by me. I'm only handling the SF release process (and I'm going to > do the next Debian release, too). Baastien said he did a freshmeat > announcement. I don't know of any other channels. I'd suggest: if > you know of a community of potential interest then make the > announcement and let us on cppunit-devel know. Ok. I'll contact Ron... Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Author of The Text Reformatter, a tool for fanfiction readers and writers. Language: English, French (Well, I'm French). |
From: Steve M. R. <ste...@vi...> - 2001-09-29 21:19:16
|
On Sat, Sep 29, 2001 at 10:39:46PM +0200, Baptiste Lepilleur wrote: > ----- Original Message ----- > From: "Steve M. Robbins" <ste...@vi...> > > Since Baptiste has already expressed interest in the FAQ, I'm > > happy to leave that to him should he wish it; otherwise I'll throw > > something together at the last minute. > > Wouldn't mean to. Though how would you organize the FAQ ? I think your three categories (windows, unix, generic) are a good start. Unfortunately, I can never predict acurately which categories will tend to be useful. I tend to start with a single category, introducing a new category when a sufficient number of related questions appear. Oh, and generic questions should probably be first in the list. > > To aid the FAQ compiler, it would be helpful to send in candidate > > questions and answers. Perhaps those of you who just joined us > > recall one or two large stumbling blocks? Or those of you reading > > the user- and help- forums see questions coming up over and over? > > > > Similarly, corrections and additions to other bits of docs would be > > greatly appreciated! In particular, the intro page (cppunit.sf.net) > > cookbook need work. Learning to use CppUnit was quite troublesome in > > my experience, so this is one area that should get extra attention, I > > feel. > I skimmed through the cookbook and I noticed that the macros are never > evoked. I think that the macros are actually the fastest way to get started > with CppUnit I agree. I was a little annoyed to learn about the macros *after* having plowed through their cumbersome alternatives. > Oh, by the way, I have those nifty Workspace Whiz template that allow > the owner of that add-ins to create a new test case class and had it to the > project in a few mouse click. Where should I put it in the CppUnit dist ? I > was thinking of contrib/msvc/. That sounds fine. -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants |
From: Baptiste L. <bl...@cl...> - 2001-09-30 14:44:10
|
----- Original Message ----- From: "Steve M. Robbins" <ste...@vi...> To: "Cpp Unit Develpment Mailing List" <cpp...@li...> Sent: Saturday, September 29, 2001 11:19 PM Subject: Re: [Cppunit-devel] 1.6.1 changes > On Sat, Sep 29, 2001 at 10:39:46PM +0200, Baptiste Lepilleur wrote: > > ----- Original Message ----- > > From: "Steve M. Robbins" <ste...@vi...> > > > > Since Baptiste has already expressed interest in the FAQ, I'm > > > happy to leave that to him should he wish it; otherwise I'll throw > > > something together at the last minute. > > > > Wouldn't mean to. Though how would you organize the FAQ ? > > I think your three categories (windows, unix, generic) are a good > start. Unfortunately, I can never predict acurately which categories > will tend to be useful. I tend to start with a single category, > introducing a new category when a sufficient number of related > questions appear. > > Oh, and generic questions should probably be first in the list. I moved the WIN32 question to doc/FAQ. It's in text format for now since I don't know how to use Doxygen to generate stuffs like a TOC, but then, there is only 4 questions... I added a generic question (to hint at the macros...) : 1.1) Isn't there an easier way to write unit tests than using TestCaller ? Yes, there is. Macros have been created to take care of the repetitive work. Look up include/extensions/HelperMacros.h in CppUnit documentation. Most of CppUnit test suite is also written that way since they remain compatible as CppUnit evolve. They also use RTTI if available. Feel free to reword. Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Author of The Text Reformatter, a tool for fanfiction readers and writers. Language: English, French (Well, I'm French). |
From: Duane M. <dua...@ma...> - 2001-09-30 03:09:22
|
--- At Sat, 29 Sep 2001 22:39:46 +0200, Baptiste Lepilleur wrote: >For #3 to make it in, someone >> (Duane?) will have to supply the relevant preprocessor symbols to >> use. I checked with some others about telling the difference between OS X and OS < X. I have not been able to locate any way of telling the compile time environments apart. I would recommend not adding this feature until I have more information in support of OS X. It may be useful to add the config-mac file to the project but not integrate it into Portability.h. A note at the top of the file would be useful. Just some suggestions. ..Duane |