petscvariables: hardwired build dir instead of install dir

Lisandro Dalcin dalcinl at gmail.com
Mon Mar 24 12:09:11 CDT 2008


On 3/24/08, Matthew Knepley <knepley at gmail.com> wrote:
> If someone explains to me in words what that sed crap is doing, I will
>  rewrite it in python.

It does not pay the effort i think. The 'sed' regexps were OK, what
was wrong was the command line arguments being passed to 'sed'; look
at the patch I've attached before, there is an empty string after the
'-i' flag, and then 'sed' thinks it is the search/replace command,
this empty str have to be removed. In short, the sed crap is actually
a typo.

However, Matt. I still think that the complete install process have to
be reviewed a bit. Just doing "cp -fr somedir/*" is not always the
best thing to do, specially as the code is changing and new stuff is
being added. And worse than that is to 'sed' in all files inside a
dir.

I'm pretty sure that the vast majority of PETSc users never 'install'
PETSc in system locations (perhaps I'm the only one). I'm completely
out of time, but at some point I'll review all this; further, I'll
develop RPM specs for building source RPM's for PETSc. When one does
this, all the mistakes in a software build system are easily
discovered.


>
>   Thanks,
>
>      Matt
>
>
>  On Mon, Mar 24, 2008 at 10:57 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>  > Barry, things are still broken. I think that at some point we have to
>  >  review the 'install:' target  more carefully.
>  >
>  >  First, the 'sed' command i being called in a wrong way.
>  >
>  >  Second, ALL files under $PETSC_ARCH/conf are being copied, I'm not
>  >  sure if all them are needed (logs, RDict.db, configure.py, etc) when
>  >  you 'install' PETSc in a central, system location.
>  >
>  >  Finally, 'sed' trickery is done under all files under 'conf/' and that
>  >  can be dangerous.
>  >
>  >
>  >  I attach a hg diff fixing some of that issues. But I still believe
>  >  that this have to be more carefully reviewed. Unfortunately, I will
>  >  not be able to do that myself for, let say, three month from now.
>  >
>  >  By using the patch in the attached file, I was able to install PETSc
>  >  and next build petsc4py. However, this does not necesarily means that
>  >  things are all OK. I already do some trickery in the build system of
>  >  petsc4py in order to 'fix' the problems with the stuff in PETSc
>  >  makefiles since version 2.3.2 until latest petsc-dev.
>  >
>  >
>  >  Regards,
>  >
>  >  On 3/22/08, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  >  > Lisandro
>  >  >
>  >  >     The rule was a total mess; I think I have fixed it now, please try
>  >  >  again
>  >  >  and let me know how it goes.
>  >  >
>  >  >    Thanks for reporting the problem,
>  >  >
>  >  >
>  >  >     Barry
>  >  >
>  >  >
>  >  >  On Mar 22, 2008, at 1:18 PM, Lisandro Dalcin wrote:
>  >  >  > OK, it seems my stderr were being sent I do not know were... I get the
>  >  >  > following (BTW, I was not aware of the 'sed' trick, but I was not
>  >  >  > seeing the error)
>  >  >  >
>  >  >  >
>  >  >  > [root at trantor petsc-dev]# make install
>  >  >  > Installing PETSc at /usr/local/petsc/dev/linux-gnu
>  >  >  > sed: can't read s?${PETSC_DIR}?TMP_INSTALL_DIR?g: No such file or
>  >  >  > directory
>  >  >  > sed: can't read s?TMP_INSTALL_DIR?/usr/local/petsc/dev/linux-gnu?g: No
>  >  >  > such file or directory
>  >  >  > sed: can't read s?/${PETSC_ARCH}??g: No such file or directory
>  >  >  > making shared libraries in /usr/local/petsc/dev/linux-gnu//lib
>  >  >  > building libpetsc.so
>  >  >  > building libpetscvec.so
>  >  >  > building libpetscmat.so
>  >  >  > building libpetscdm.so
>  >  >  > building libpetscksp.so
>  >  >  > building libpetscsnes.so
>  >  >  > building libpetscts.so
>  >  >  > building libpetsccontrib.so
>  >  >  > sh/bash: PETSC_DIR=/usr/local/petsc/dev/linux-gnu; export PETSC_DIR
>  >  >  > sh/bash: unset PETSC_ARCH
>  >  >  > csh/tcsh: setenv PETSC_DIR  /usr/local/petsc/dev/linux-gnu
>  >  >  > csh/tcsh: unsetenv PETSC_ARCH
>  >  >  > Then do make test to verify correct install
>  >  >  >
>  >  >  >
>  >  >  > And then the 'petscvariables' still have the build dir in many places.
>  >  >  > So the 'sed' command is not working for me. I do not know way, I've
>  >  >  > never had the time to learn regexps :-(.
>  >  >  >
>  >  >  > BTW, I'm on a Fedora 6 box.
>  >  >  >
>  >  >  >
>  >  >  > On 3/22/08, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  >  >  >>
>  >  >  >>   Ok, I think I understand your concern,
>  >  >  >>
>  >  >  >>
>  >  >  >> On Mar 22, 2008, at 9:00 AM, Lisandro Dalcin wrote:
>  >  >  >>
>  >  >  >>> On 3/22/08, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  >  >  >>>>     Do you mean that it lists, for example,
>  >  >  >>>> SUPERLU_DIST_LIB = -Wl,-rpath,/Users/bsmith/Src/petsc-dev/arch-icc-
>  >  >  >>>> superlu_dist/lib -L/Users/bsmith/Src/petsc-dev/arch-icc-
>  >  >  >>>> superlu_dist/
>  >  >  >>>> lib -lsuperlu_dist_2.2
>  >  >  >>>> instead of
>  >  >  >>>> SUPERLU_DIST_LIB = -Wl,-rpath,$PETSC_DIR/arch-icc-superlu_dist/
>  >  >  >>>> lib -L
>  >  >  >>>> $PETSC_DIR/arch-icc-superlu_dist/lib -lsuperlu_dist_2.2
>  >  >  >>>>
>  >  >  >>>
>  >  >  >>> exactly that, as an example, I've just built petsc-dev, passing as
>  >  >  >>> prefix the following '--prefix=/usr/local/petsc/2.3.3/linux-
>  >  >  >>> gnu' (yes,
>  >  >  >>> I still want to have multiconfig installations of petsc in a central
>  >  >  >>> location, so I add the PETSC_ARCH to the prefix)
>  >  >  >>>
>  >  >  >>> But the 'petscvariables' file stills says, for example
>  >  >  >>>
>  >  >  >>> ML_INCLUDE = -I. -I/usr/local/mpich2/1.0.6/include
>  >  >  >>> -I/usr/local/mpich2/1.0.6/include
>  >  >  >>> -I/repos/hg/petsc/petsc-dev/linux-gnu/include
>  >  >  >>
>  >  >  >>
>  >  >  >>    This is because the place we want ML to install itself has be
>  >  >  >> passed in as the true path, it cannot be sent as a symbolic PETSC_DIR
>  >  >  >> since configure of the subpackage doesn't know PETSC_DIR
>  >  >  >>
>  >  >  >>
>  >  >  >>>
>  >  >  >>>
>  >  >  >>> The last include dir is the directory were I've built PETSc. I would
>  >  >  >>> love to see that include as -I${PETSC_DIR}/${PETSC_ARCH}/include.
>  >  >  >>> And
>  >  >  >>> now, if external packages got installed in $PETSC_DIR/$PETSC_ARCH,
>  >  >  >>> we
>  >  >  >>> perhaps could just put nothing, as that location is always taken
>  >  >  >>> into
>  >  >  >>> accout for PETSc itself.
>  >  >  >>>
>  >  >  >>> The real problem: if I remove the build dir, the 'petscvariables'
>  >  >  >>> point to locations that no longer exists, This is dangerous. I
>  >  >  >>> already
>  >  >  >>> had trouble in the past with the old 'bmake' based system. Is
>  >  >  >>> there a
>  >  >  >>> chance to 'fix' this, or I'm missing something?
>  >  >  >>
>  >  >  >>
>  >  >  >>   make intall: see the rule in makefile is suppose to replace all
>  >  >  >> uses of the
>  >  >  >> petsc-dir directory with the final prefix installed location: the
>  >  >  >> lines
>  >  >  >>
>  >  >  >>           sed -i "" 's?$${PETSC_DIR}?TMP_INSTALL_DIR?g' $
>  >  >  >> {INSTALL_DIR}/conf/* ;\
>  >  >  >>           sed -i "" s?TMP_INSTALL_DIR?${INSTALL_DIR}?g $
>  >  >  >> {INSTALL_DIR}/
>  >  >  >> conf/* ;\
>  >  >  >>
>  >  >  >> would replace
>  >  >  >>
>  >  >  >>
>  >  >  >> /repos/hg/petsc/petsc-dev/linux-gnu/include
>  >  >  >>
>  >  >  >> /usr/local/petsc/2.3.3/linux-gnu/include
>  >  >  >>
>  >  >  >> Now it could be that the sed is not working when you run install? Can
>  >  >  >> you do a
>  >  >  >> config/configure.py with a --prefix then the make then the make
>  >  >  >> install and see what
>  >  >  >> goes wrong?
>  >  >  >>
>  >  >  >>
>  >  >  >>   Barry
>  >  >  >>
>  >  >  >>
>  >  >  >> with
>  >  >  >>
>  >  >  >>
>  >  >  >>
>  >  >  >>>
>  >  >  >>>
>  >  >  >>>
>  >  >  >>>
>  >  >  >>> --
>  >  >  >>> Lisandro Dalcín
>  >  >  >>> ---------------
>  >  >  >>> Centro Internacional de Métodos Computacionales en Ingeniería
>  >  >  >>> (CIMEC)
>  >  >  >>> Instituto de Desarrollo Tecnológico para la Industria Química
>  >  >  >>> (INTEC)
>  >  >  >>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>  >  >  >>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>  >  >  >>> Tel/Fax: +54-(0)342-451.1594
>  >  >  >>>
>  >  >  >>
>  >  >  >>
>  >  >  >
>  >  >  >
>  >  >  > --
>  >  >  > Lisandro Dalcín
>  >  >  > ---------------
>  >  >  > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
>  >  >  > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
>  >  >  > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>  >  >  > PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>  >  >  > Tel/Fax: +54-(0)342-451.1594
>  >  >  >
>  >  >
>  >  >
>  >
>  >
>  >  --
>  >  Lisandro Dalcín
>  >  ---------------
>  >  Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
>  >  Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
>  >  Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>  >  PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>  >  Tel/Fax: +54-(0)342-451.1594
>  >
>
>
>
>
> --
>  What most experimenters take for granted before they begin their
>  experiments is infinitely more interesting than any results to which
>  their experiments lead.
>  -- Norbert Wiener
>
>


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594




More information about the petsc-dev mailing list