On Fri, Nov 27, 2009 at 1:45 PM, Lisandro Dalcin <span dir="ltr"><<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, Nov 27, 2009 at 4:33 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
><br>
> Why not just hash the RDict.db?<br>
><br>
<br>
</div>Could work, though it could be a bit too much. For example, would the<br>
hash remains the same after rebuild and reinstall a PETSc<br>
patch-release? IIUC, there should be no need to rebuild and reinstall<br>
SLEPc after a patch-release upgrade of PETSc.<br><div><div class="h5"></div></div></blockquote><div><br>IIUC? I do not text.<br><br>I would say even bitwise comparison of the pickle is fine. If it changes, you need<br>to reconfigure PETSc, and that means reconfiguring SLEPc.<br>
<br>  Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5">
<br>
>   Matt<br>
><br>
> On Fri, Nov 27, 2009 at 1:24 PM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, Nov 27, 2009 at 2:21 AM, Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br>
>> ><br>
>> > The way I look at it - the primary complexity here is from PETSc<br>
>> > buildsystem.<br>
>> ><br>
>> > Because PETSc buildsystem supports both types of builds - 'prefix' and<br>
>> > 'regular' - one is forced to use PETSC_ARCH 'during build process' -<br>
>> > even with a prefix build [even though it doesn't make any sense to<br>
>> > this gnu build model].<br>
>> ><br>
>> > Once we force this on users - I don't think we are justified in<br>
>> > removing traces of this intermediate step - if slepc/petsc4py would<br>
>> > like to use info.<br>
>> ><br>
>><br>
>> Indeed. SLEPc/TAO and {petsc|slepc|tao}4py are not normal "users" of<br>
>> PETSc.<br>
>><br>
>> > To me - it makes perfect sense for these packages to mimick both the<br>
>> > PETSc build modes as closly as possible [both modes]. So if they need<br>
>> > PETSC_ARCH used during PETSc build - then thats fine.  Perhaps it<br>
>> > should be named PETSC_ARCH_value_used_at_build_time - or a more<br>
>> > descriptive name to satisfy Barry's concerns.<br>
>> ><br>
>><br>
>> The whole point of my concerns is that I need to have some sort of<br>
>> "unique-identifier" that let me know a SLEPc build match a PETSc<br>
>> build. For non-prefix builds of PETSc and SLEPc, that is PETSC_ARCH.<br>
>> For prefix installs, I've somewhat lost my way to make sure PETSc and<br>
>> SLEPc builds match each other.<br>
>><br>
>> Could we devise a way to generate a Makefile variable embeding some<br>
>> info from the most basic configuration setup, for example a string<br>
>> with coma-separated key:value pairs, something like,<br>
>><br>
>> PETSC_CONF =<br>
>> "platform:linux2,arch:i686,compiler:gnu,language:c,debug:no,integer:32bit,scalar:real,precision:double"<br>
>><br>
>> and any other important bit I could be missing?<br>
>><br>
>> This way, SLEPc's configure could get the value from parsing PETSc<br>
>> makefiles, and then SLEPc could save that value in its own makefiles.<br>
>> Then petsc4py/slepc4py could use that info (at build time and runtime)<br>
>> to have some sort of assurance that libraries from the PETSc build and<br>
>> the SLEPc build are more or less compatible, and can be used together.<br>
>> You know, errors should never pass silently :-)<br>
>><br>
>> What do you think?<br>
>><br>
>><br>
>> --<br>
>> Lisandro Dalcín<br>
>> ---------------<br>
>> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
>> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
>> Tel/Fax: +54-(0)342-451.1594<br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments<br>
> is infinitely more interesting than any results to which their experiments<br>
> lead.<br>
> -- Norbert Wiener<br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">Lisandro Dalcín<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>