neopragma / cobol-unit-test

Unit testing framework and sample code for batch Cobol programs.
GNU General Public License v3.0
117 stars 36 forks source link

The GnuCOBOL project, and some small 2.0 issues. #77

Open btiffin opened 9 years ago

btiffin commented 9 years ago

@neopragma Would you be up for including this code as a contrib/ entry with the GnuCOBOL project?

Or, if you are up for even more, having it included with the product as an extras/? It would be put in as

./configure --with-unit
make

(or some other configurable name), and be installed along with GnuCOBOL, ready to roll.

Second choice would require a rights reassignment to the Free Software Foundation and either a GPL or LGPL license, (we are a GNU free software project), so you would need to think about it, but this is some nice code Dave, nice. Inclusion in contrib/ is more flexible on licensing as it's an community based tarball, but it would be awesome addition to the product.

If you are up for it, I'd volunteer to update the autotools scripts, tweak your documentation for GNU Texinfo formatting, and put in a couple of make check tests, then hand over write permissions so you would still be in charge of the source tree.

And now to a few small issues with running the samples:

I had to tweak two small things with current GnuCOBOL 2.0. Names are stricter at 30 characters, by standard, unless the -frelax-syntax option is included with cobc. When I changed the compile script, it complained as $COBOPTS was passed as quoted, so "-x -frelax" was passed incorrectly to cobc. The other small issue is a more strict ambiguity change regarding LENGTH OF and FUNCTION LENGTH (for when FUNCTION ALL INTRINSIC is mentioned in a REPOSITORY paragraph. With 2.0, the OF keyword is mandatory to distinguish usage, LENGTH OF. Effected src/main/cobol/CONVERT.CBL and CONVER2.CBL in the calls to "C$TOUPPER". Other than that ./run-examples worked the charm on Fedora 21, with GnuCOBOL 2.0-ReportWriter.

I put in a mention at https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#Cobol by the by, and I'll be writing up a full blurb in the GnuCOBOL FAQ document shortly.

Cheers

neopragma commented 9 years ago

Brian, please tell me more about the contrib/ option.

Thanks, Dave

btiffin commented 9 years ago

If you'd like to see it in action, we're currently on SourceForge, http://sourceforge.net/p/open-cobol/contrib/HEAD/tree/ currently SVN. You'd just need commit permissions. But ... that's also divisive when it comes to maintaining two repositories.

Due to the press around SourceForge and some moves by Dice Holdings, we have plans for a self hosted Allura install, same base forge software, just not SourceForge. When that gets set up, I'd be more than happy to turn up Git, and perhaps we could simply mirror a repo, to avoid adding a bunch of sideways work on your end.

Anyway, if you are up for it, I'd really like to get cobol-unit-test included as a direct or indirect feature advertised to GnuCOBOL developers. It's in the FAQ already, links pointing to here on GitHub, http://opencobol.add1tocobol.com/gnucobol/#what-is-cobol-unit-test but adding a blurb that it's the projects preferred unit test head, and making it easier for GnuCOBOL developers to dive in, would be sweet.

Thanks again, Dave

Oh, by the by, is cobol-unit-test a preferred name? Or is the project ZUT, or the like, when you talk about it, and/or advertise?

I really would like to cheerlead for this with the GnuCOBOL folk. I know you are targeting z/OS, but I'm also keen on documenting where safe common ground between big iron and small tin COBOL is, so I see benefits to both. Your "reads like COBOL" DSL for COBOL paragraph testing needs more press. And small tin COBOL programmers need more unit testing. :-)

Cheers