This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ObjC/ObjC++: bug fixes for @catch
On 29 Nov 2010, at 19:40, Mike Stump wrote:
On Nov 29, 2010, at 12:30 AM, IainS wrote:
FWIW, for example: make check-objc RUNTESTFLAGS="strings.exp=* "
--- will run all the .dg _and_ .dg/torture string tests ... which I
think is useful.
Well, except this doesn't work for things that don't have an .exp
file... :-( The dg.exp=cfstring\*.m method does work, always.
Of course, one needs to decide on what constitutes a 'major'
category.
In general, I'd prefer most testcases to fit in a very small number
of framework drivers. I'm not in favor of just randomly creating
new drivers for the sole purpose of providing group naming. We
create them, when the existing drivers can't meet the needs and
should not be extended to meet those needs. This in general means,
no major categories, rather, we have specific needs, like, lto, dg,
torture. These aren't categories of testcases, but rather,
different sets of specialized needs of test cases.
Now, when to create a new driver or fold it into an existing one.
It must be handled on a case by case basis. In general, if an
existing driver would work, I prefer using it. Only when that
doesn't work, and the feature set needed doesn't fit into the
framework, we create a new driver.
OK. That's reasonable, and I can re-jig things to replace the
additional drivers with a facility to drive a list of sub-dirs from
the dg.exp, lto.exp and dg-torture.exp
(that doesn't seem like a major headache).
The only loss there is the ability to drive disjoint sets ..
... as you point out, that can only be achieved if we proliferate
drivers (which was where I was heading ;) ).
- but I believe having everything in one place is not the way to
facilitate easy maintenance.
I don't follow. dg.exp=eh-*.C for example is isomorphic to
dg.exp=eh/*.C, which is isomorphic to eh.exp, Now, if your only
complaint is that eh.exp is a few characters shorter, well, yes,
this is true...
well, I'd argue for eh/
-- it has an interesting property that test-cases need not be named
"eh-*"
-- if there is a more logical name (e.g. PRxxxx) but it will still be
clear that they are tests related to eh.
What are the 4 most important qualities you're interested in?
thanks, that's a useful question.
1. A Plan that's clear, reasonably robust to growth and explicable to
new and existing developers in moderate documentation.
(since the ObjC test-suite is currently undocumented - and it does
take time to get to grips with it)
2. an organization that makes it clear what is grouped together
-- so that new and existing developers can find what's been tested
and not duplicate tests or effort.
3. if possible, the ability to run groups of related tests (preferably
without excessive keystrokes) such that when working on one aspect of
the FE one can reasonably quickly get feedback on problems.
4. I'd prefer to avoid dg.exp (or any other dir) growing until it is
2000 files and the job is Too Big to fix it .. (but that might be a
restatement of 1..3 ;-) )
-- we are already heading for 250 tests in dg.exp (and it would be
nearer 450 without the ones we've already split out).
Mechanically, I think this can be done with dg.exp=<group-dir>/*.m ..
as well as group.exp=*.m ...
... so I'm happy to retire the three or so 'un-necessary' .exp files
and figure out a change to dg/lto/dg-torture.exp to handle the sub-dirs.
I guess the pre-requisite is the bare-bones of (1) - or effort in re-
organizing things is wasted (and time is a short-supply resource).
P.S. I guess we need to reach consensus [ or have a ruling :-) ]
since
(a) we're expanding the test-suite quite fast at the moment
(b) I was intending to document it before 4.6 goes out
Wait, consensus, I thought we practiced benevolent dictator? :-)
dang, and I thought this was floating anarchy :-)
Now, as a directory balloons out, yes, we tend to split testcases
out, so for example, today we might have exception-1.m, and tomorrow
it may well be exception/exception-1.m... We aren't quite there yet.
It creeps up on you...
... you might be surprised to count up and see that we've almost
doubled the ObjC test-case count (and more than doubled the ObjC++
count) since 4.5 forked.
Yes, we're still less than 10% of the C and C++ suites, but we're way
less than 10% of their maintainer count too ;-)
cheers
Iain