> > Implicit criticism about tests accepted. I have 679 UAT tests, and
> > now I've got the bit in my teeth, and I am creating a process that
> > will convert as many as I can to DejaGnu. However: the autom4te and
> > DejaGnu principles, practices, and philosophies are almost, but not
> > quite, completely unlike each other.
>
> Didn't mean to criticize in any way, just mention that because we have
> just 23 tests so far, the UAT/NIST testing you are doing is a
> precondition for any non-trivial FE changes and that testing wasn't
> done on my side.
While I'm feeling like the old grumpy man I possibly am sometimes by
asking the same question over and over again... let me make this
explicit one time to this list (as I've not seen a response on-list to
that, sorry if I missed it):
<grumpy>
Is there any reason at all why the UAT should not be added to trunk,
like immediately, even if it is only temporary?
I totally see the point that sticking with what the project *mostly*
uses (not all frontends do use DejaGnu!) is reasonable. I also see that
the way it is setup (running the same tests multiple times with
different options) is better than what the UAT currently does (I can
offer help to do something similar with autotest generated testsuite as
we did do that in GnuCOBOL in the past), but I mostly see:
* there are very reasonable testcases
* there are a lot testcases
* again and again contributors don't know if their changes are fine,
because the DejaGnu part doesn't cover them; and patches sent in
need to be tested by COBOLworx
* UAT doesn't need any additional software - it is just autoconf, make,
shell and is portable in general (cross-compiling without executing
would need adjustments "AT_SKIP" or assigning a shell script that
exits with 77 instead of running the program)
* the whole testsuite is either already copyrighted by the FSF (the
parts that were taken from GnuCOBOL) or COBOLworx (changes and new
tests) - and the tests converted to DejaGnu are also contributed by
COBOLworx so there should be no problem in contributing UAT directly
* converting tests to DejaGnu takes time from Bob, and there's only a
single Bob available - while bugzilla gets new entries that would also
need his focus
Overall my conclusion is: Time seems to be spent MUCH more useful for
everyone if UAT would just be added as-is for now. I should be able to
provide some patches to run it multiple times with different options
(like DejaGnu does), if wanted, as well.
GCC-15 could ship with the generated testsuites, so the user does not
need any additional tools as well, and if really wanted all of UAT could
be converted to DejaGnu for GCC-16.
Plain question again:
Is there any reason at all why the UAT should not be added to trunk,
like immediately and *potentially* the move to DejaGnu be postponed?
A _separate_ issue is the question if NIST could be checked in as well,
configured to not run automatically (so independent from users or build
recipes) but this way being possible to be executed on the contributor
side easily?
If not: what about making the "nist" sub-folder a tarball that can just
be extracted to gcc/cobol and then be used on the contributor side
(there's no autotools stuff in there, so that would be possible)?
</grumpy>
Kind regards and thanks for your work on COBOL,
Simon
