knepley at mcs.anl.gov
Sun Sep 25 19:03:25 CDT 2005
S V N Vishwanathan <vishy at mail.rsise.anu.edu.au> writes:
> I am tying myself up in knots in trying to figure out your BuildSystem
> and how to adapt it to LINEAL. PETSc is one primary component of LINEAL
> but going forward there will be others (viz. TAO, OOQP).
> I want that my users should be exposed to one and only one config + make
> step if possible. A typical user interaction should be as follows:
> 1) If PETSc exists under $LINEAL_DIR/externalpackages and is configured
> and built with the right switches then we just build LINEAL.
> 2) If the user wishes to use their own custom PETSc then they just
> specify --with-petsc-dir= and I should be able to pick it up from
> 3) If neither 1 nor 2 is true then I should offer to download, configure
> and build PETSc (much akin to what the current PETSc build scripts
> currently do).
> I am unclear about where external packages required by PETSc should
> go. Many packages (like PETSc, TAO, OOQP) might want to use some common
> external package (like MPICH). But it seems like a wasted effort if we
> replicate the PETSc build scripts which already install these packages
> into $PETSC_DIR/externalpackages.
PETSc does have --with-external-packages-dir, which defaults to
$PETSC_DIR/externalpackages, but you can initialize it to whatever you want.
> When I try to grab the framework object from RDict.db and use a require
> method on it, it seems to bomb because many of the scripts in
> $PETSC_DIR/python/PETSc seem to make an implicit assumption that the
> configure scripts are run from $PETSC_DIR (a bad assumption I think, esp
> given that you have the PETSC_DIR variable available to you).
We would be willing to work on this with you. That requirement has been
discussed. The point of view from the other side is that users (very) often
get confused and we would like to do as much as possible to make sure they
are doing the correct thing (like installing from PETSC_DIR). Also, we
never assume that PETSC_DIR is defined during configure. That said, I'm
sure these outright dependencies can be fixed.
> The lack of documentation adds to my woes. I don't want to be a cry
> baby, but I did spend considerable time and effort trying to figure
> things out and still don't have a good feel for how different scripts
I tried to document the configure (Python) part as much as I could. I
know the make part is not documented, but it is an artifact of an earlier
age when make systems were considered the equivalent of hammers, which
are rarely documented. Feel free to mail questions.
> So my question is simple, if you were in my position i.e. designing the
> build scripts for LINEAL, how would approach the problem?
I would decide up front whether I wanted to use:
c) something totally new
>From this basic design decision flows almost every other decision. Also, it
gives you an idea of what kind of investment is necessary. I will try and
indicate why I choose c). The kind of work involved in making a new system
is different and appeals to me. If you use a), generally you spend lots of time
writing shell and working out bizzare tricks with stamp files to get flow
control. If you choose b), you spend lots of time understanding someone else's
system, and for autotools that means even more, even more baroque shell.
With c), you have to write much more and work things out, but you can fix
many things and perhaps introduce a more powerful paradigm. However, all
projects are different and all options shuold be considered every time.
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness
More information about the petsc-dev