new build system

Lisandro Dalcin dalcinl at gmail.com
Wed Jun 13 20:14:35 CDT 2007


On 6/13/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
> On Wed, 13 Jun 2007, Lisandro Dalcin wrote:
> > Additionally, IMHO we should not make a mess in
> > those standard locations with many headers and libraries.
>
>   I agree, but standard filesystem structures may dictate dumping
> directly into lib and include, thus making them a mess.

I am using Fedora Core 6, I've installed ATLAS rpm, see the contents:

$ rpm -ql atlas
/etc/ld.so.conf.d/atlas-i386.conf
/usr/lib/atlas
/usr/lib/atlas/libatlas.so.3
/usr/lib/atlas/libblas.so.3
[snip]
/usr/share/doc/atlas-3.6.0
[snip]

$ rpm -ql atlas-devel
/usr/include/atlas
/usr/include/atlas/atlas_altivec.h
[snip]
/usr/lib/atlas/libatlas.a
/usr/lib/atlas/libblas.a
[snip]

I really like this!!! Note the ''/etc/ld.so.conf.d/atlas-i386.conf"
file. This solves the problem for runtime linking.

>   It bothers me greatly to sometimes have PETSc installed in /usr/lib/petsc..
> and other times in /opt/petsc/.... Having two models is confusing.

I agree, I was just suggesting a way of providing 'optional' petsc
build for 'power' users.

> Why don't we always dump into /opt/petsc? Everything is easy! Why make
> life complicated by also supporting the /usr/lib approach? Do
> some systems/people not use the /opt?

The usage of '/opt' is not so standard as '/usr'.


> > NEXT, build system sould be updated to be able to manage 'installed'
> > versions and 'build' versions... This would possibly make the 'build'

>   I do not understand what you are saying. what do you mean by
> "build system"? Do you mean the PETSc makefiles? What do you mean by
> "manage"? Create them initially or manage updates to the installed
> version over time?

We should define first the filesystem structure for a 'install'
version, and next redesign build system to be able to cope the
'install' mode (PETSC_ARCH-less) and 'build' mode (using PETSC_ARCH).
For this, the build directory (what you get after tar -zxf
petsc.tar.gz, or the local hg repo) would possibly have a ugly
structure, but this uglyness should not be taken into account. The
main goal IS installing and packaging, not to have a build directory
with a shallow, clean structure.



-- 
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