Ok, so you are suggesting the same functions/options database as today
except that : separated strings for alternatives?
Note that PetscFListGetPathAndFunction() which is used by all the checkers
handles the form [/path/libname[.so.1.0]:]functionname[()] so : is already
reserved. I would suggest | but the damn shell would require always protecting
the arguments with "".
Barry
On Jan 7, 2013, at 5:09 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Mon, Jan 7, 2013 at 5:02 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> How would this be done in the code? Ideally there is a functional interface
> with a corresponding OptionsData base interface. Something like the
> equivalent of
> PCFactorSetMatSolverPackages(pc,{MATSOLVERSUPERLU_DIST,MATSOLVERMUMPS,
> MATSOLVERPETSC,PETSC_NULL})
>
> It could, but I'd prefer to have a generic routine that created an
> alternative from the array of types (by joining them with ':').
>
> Otherwise it's just more boilerplate for every object.
>
> Then follow this paradigm for all set types and packages? But then since
> there is a PCFactorSetMatSolverPackage() and a
> PCFactorSetMatSolverPackages() should there be
> a -pc_factor_mat_solver_package package AND -pc_factor_mat_solver_packages
> package1:package2 ?
>
> No need, if it containts a ':' then it's an alternative. The implementation
> of PCFactorSetMatSolverPackages() would just join the strings and call
> PCFactorSetMatSolverPackage().
