On Thu, 10 Jan 2008, [EMAIL PROTECTED] wrote:
> Some hand-waving on the problem of configuration and test selection, (as
> the two appear to share the issues, an ideal solution would address both).
>
> For any usable environment, a large set of common processes have to be
> executed, with a smaller, OS &&/|| CPU specific set omitted. One way to do
> this might be to have all possible steps in a common process directory,
> with a mechanism to drop the unwanted ones. Any process invoked could
> assume that it has the right to run.
>
> A possible scheme might be a directory hierarchy matching the OS/CPU
> combination, e.g. Linux/x_86, Linux/i_64, Solaris/Sparc, containing dummy
> files whose names match the processes NOT to be run for that environment.
> (The precise structure would depend on which combination required the
> fewest cases; it's dictated by the data.)
At least for configuration, I think it's generally better to depend on
specific features, not OS/CPU combinations. I suspect the same is true
for testing.
For example, if a test depends on 64-bit integer operations, it should
only matter whether or not the current build supports 64-bit integer
operations. That could, of course, depend on the OS/CPU combination, but
it will also depend on the compiler and compiler flags used.
More generally, whether a particular thing will work on a given system may
depend on a whole host of things, such as the version and patchlevel of
the compiler, optional compiler flags, the version and patchlevel of the
operating system, the precise CPU (does it have the SSE instruction?)
optional add-on libraries, etc.
Consider too, how much duplication there would be. Just considering two
operating systems (Linux and Solaris), three architectures (SPARC, x86,
i64) and two compilers (suncc, gcc), that's 12 directories. (More
actually, since icc runs on Linux/x86. And I haven't even mentioned
different versions of the same OS (e.g. Linux 2.4 vs 2.6). Worse, I
haven't even discussed the entire BSD family yet, whose members are
generally quite similar, except when it comes to those fuzzy areas where
you might have to skip hanging tests.
As you very correctly note,
> (The precise structure would depend on which combination required the
> fewest cases; it's dictated by the data.)
I think the data will support the idea that a directory structure based on
OS/CPU is probably not the way to start.
Instead, one might consider generating that list of exclusions based on
the actual results of running Configure.pl. The program that generated
that skip list might consist of lines like
print "t/op/64bit.t" unless $PConfig{intvalsize} == 8;
(This also obviously allows easier generalizations, such as 'skip this for
libfoo versions less than 2.0.8, or for versions 2.1.0 through 2.1.3). It
also tries to keep all the relevant information closer together -- the
"skip list" and the reasoning behind each skip are kept in the same place,
not scattered all over dozens of directories.
--
Andy Dougherty [EMAIL PROTECTED]
