[petsc-dev]    Re:  [petsc-maint] valgrind detected on   /usr/local/include and enabled but header files from this dir are not added to build path

Åsmund Ervik asmund.ervik at ntnu.no
Tue Oct 29 15:39:31 CDT 2013


Barry:

Re: "Nobody uses more than two $PETSC_ARCH": We have our regression tests run on a machine with 8 different ones (4 Fortran compilers each with debug and optim). This is using stable releases, but there could be people doing the same with maint I guess.

Åsmund


Sent from my VT-102

petsc-dev-request at mcs.anl.gov skrev:
Send petsc-dev mailing list submissions to
        petsc-dev at mcs.anl.gov

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev
or, via email, send a message with subject or body 'help' to
        petsc-dev-request at mcs.anl.gov

You can reach the person managing the list at
        petsc-dev-owner at mcs.anl.gov

When replying, please edit your Subject line so it is more specific
than "Re: Contents of petsc-dev digest..."


Today's Topics:

   1. Re:  [petsc-maint] valgrind detected on   /usr/local/include
      and enabled but header files from this dir        are not added to build
      path (Barry Smith)
   2. Re:  [petsc-maint] valgrind detected on   /usr/local/include
      and enabled but header files from this dir        are not added to build
      path (Jed Brown)
   3. Re:  [petsc-maint] valgrind detected on   /usr/local/include
      and enabled but header files from this dir        are not added to build
      path (Satish Balay)
   5. Re:  [petsc-maint] valgrind detected      on      /usr/local/include
      and enabled but header files from this    dir     are not added to build
      path (Barry Smith)
   6. Re:  [petsc-maint] valgrind detected      on      /usr/local/include
      and enabled but header files from this    dir     are not added to build
      path (Barry Smith)
   7. Re:  [petsc-maint] valgrind detected on   /usr/local/include
      and enabled but header files from this dir        are not added to build
      path (Jed Brown)
   8. Re:  [petsc-maint] valgrind detected on /usr/local/include
      and enabled but header files from this dir are not added to build
      path (Aron Ahmadia)
   9. Re:  [petsc-maint] valgrind detected      on      /usr/local/include
      and enabled but header files from this    dir     are not added to build
      path (Satish Balay)


----------------------------------------------------------------------

Message: 1
Date: Tue, 29 Oct 2013 13:49:34 -0500
From: Barry Smith <bsmith at mcs.anl.gov>
To: Jed Brown <jedbrown at mcs.anl.gov>
Cc: For users of the development version of PETSc
        <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on
        /usr/local/include and enabled but header files from this dir   are not
        added to build path
Message-ID: <719930D7-E33C-42CE-8252-2CB5BAEBD3B9 at mcs.anl.gov>
Content-Type: text/plain; charset=windows-1252


On Oct 29, 2013, at 9:04 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>    Could you please add a ?with-clean (or better name?) option to ./configure that does the $PETSC_ARCH removal business? Then we can just run
>>
>>    $PETSC_ARCH/conf/reconf*.py  ?with-clean
>
> I guess this also has to delete relevant parts of externalpackages to
> make sure the current version of packages get downloaded.
>
> Part of me wants to put all the externalpackages inside $PETSC_ARCH
> because the source is usually smaller than the object files or the

   Or simpler just have the ?with-clean nuke external packages; makes life easy.  By "store the tarballs in a common place? and SHA1 crap you are making the system more complicated to understand and maintain.


   Barry

> compiled binary, so we're not saving anything by unpacking in a common
> location.  We could store the tarballs in a common place and include
> their SHA1 in ${package}.py so that BuildSystem could match the correct
> tarball and unpack it cleanly.



------------------------------

Message: 2
Date: Tue, 29 Oct 2013 12:51:57 -0600
From: Jed Brown <jedbrown at mcs.anl.gov>
To: Barry Smith <bsmith at mcs.anl.gov>
Cc: For users of the development version of PETSc
        <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on
        /usr/local/include and enabled but header files from this dir   are not
        added to build path
Message-ID: <87bo27ucz6.fsf at mcs.anl.gov>
Content-Type: text/plain; charset="utf-8"

Barry Smith <bsmith at mcs.anl.gov> writes:
>    Or simpler just have the ?with-clean nuke external packages; makes
>    life easy.  By "store the tarballs in a common place? and SHA1 crap
>    you are making the system more complicated to understand and
>    maintain.

People will complain when they have to download the same tarball many
times.  But I don't especially care as long as the builds are done
inside $PETSC_ARCH instead of in a common place.  (This is also useful
when building multiple configurations of PETSc in parallel.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/dd42a127/attachment-0001.pgp>

------------------------------

Message: 3
Date: Tue, 29 Oct 2013 13:59:49 -0500 (CDT)
From: Satish Balay <balay at mcs.anl.gov>
To: Jed Brown <jedbrown at mcs.anl.gov>
Cc: For users of the development version of PETSc
        <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on
        /usr/local/include and enabled but header files from this dir   are not
        added to build path
Message-ID: <alpine.LFD.2.03.1310291353210.3576 at mcs.anl.gov>
Content-Type: text/plain; charset="utf-8"

On Tue, 29 Oct 2013, Jed Brown wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
> >    Or simpler just have the ?with-clean nuke external packages; makes
> >    life easy.  By "store the tarballs in a common place? and SHA1 crap
> >    you are making the system more complicated to understand and
> >    maintain.
>
> People will complain when they have to download the same tarball many
> times.  But I don't especially care as long as the builds are done
> inside $PETSC_ARCH instead of in a common place.  (This is also useful
> when building multiple configurations of PETSc in parallel.)

There is also the issue with git repos to deal with. [presumably the
above logic would be slightly different than the tarballs]

We [Jed and I ] also discussed having git repos and corresponding
tarballs match - and caching tarballs locally for unreliable external
sites. And then using SHA as a way of versioning to eliminate most
cases where with-clean would be needed.

Just a note: all these issues are primarily with git users - not
petsc-release/tarball users.

Satish

------------------------------

Message: 4
Date: Tue, 29 Oct 2013 14:06:16 -0500
From: Barry Smith <bsmith at mcs.anl.gov>
To: Jed Brown <jedbrown at mcs.anl.gov>
Cc: For users of the development version of PETSc
        <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on
        /usr/local/include and enabled but header files from this dir   are not
        added to build path
Message-ID: <9BC093D9-4FDF-4496-A8BD-260914B949FE at mcs.anl.gov>
Content-Type: text/plain; charset=windows-1252


On Oct 29, 2013, at 1:51 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>   Or simpler just have the ?with-clean nuke external packages; makes
>>   life easy.  By "store the tarballs in a common place? and SHA1 crap
>>   you are making the system more complicated to understand and
>>   maintain.
>
> People will complain when they have to download the same tarball many
> times.  But I don't especially care as long as the builds are done
> inside $PETSC_ARCH instead of in a common place.  (This is also useful
> when building multiple configurations of PETSc in parallel.)

   Besides us, hardly anyone uses more than 2 PETSC_ARCH!

   So how about just moving externalpackages into $PETSC_ARCH and don?t build some elaborate scheme that reuses tar balls for a tiny number of people.  In other words a clean truly means clean and gets new tar balls.

   Barry




------------------------------

Message: 5
Date: Tue, 29 Oct 2013 14:07:31 -0500
From: Barry Smith <bsmith at mcs.anl.gov>
To: petsc-dev <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected        on
        /usr/local/include and enabled but header files from this       dir     are not
        added to build path
Message-ID: <C37092D2-4C26-4F1A-91B6-21C8E7408ADC at mcs.anl.gov>
Content-Type: text/plain; charset=windows-1252


  It is not worthy any additional logic in the already messing configure process to save a few downloads.

   Barry


On Oct 29, 2013, at 1:59 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Tue, 29 Oct 2013, Jed Brown wrote:
>
>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>>   Or simpler just have the ?with-clean nuke external packages; makes
>>>   life easy.  By "store the tarballs in a common place? and SHA1 crap
>>>   you are making the system more complicated to understand and
>>>   maintain.
>>
>> People will complain when they have to download the same tarball many
>> times.  But I don't especially care as long as the builds are done
>> inside $PETSC_ARCH instead of in a common place.  (This is also useful
>> when building multiple configurations of PETSc in parallel.)
>
> There is also the issue with git repos to deal with. [presumably the
> above logic would be slightly different than the tarballs]
>
> We [Jed and I ] also discussed having git repos and corresponding
> tarballs match - and caching tarballs locally for unreliable external
> sites. And then using SHA as a way of versioning to eliminate most
> cases where with-clean would be needed.
>
> Just a note: all these issues are primarily with git users - not
> petsc-release/tarball users.
>
> Satish



------------------------------

Message: 6
Date: Tue, 29 Oct 2013 14:08:08 -0500
From: Barry Smith <bsmith at mcs.anl.gov>
To: petsc-dev <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected        on
        /usr/local/include and enabled but header files from this       dir     are not
        added to build path
Message-ID: <0C021837-7C75-47D3-9CAC-39D582955549 at mcs.anl.gov>
Content-Type: text/plain; charset=windows-1252


   Just because you can do it doesn?t mean you should do it.

   Barry

On Oct 29, 2013, at 2:07 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>  It is not worthy any additional logic in the already messing configure process to save a few downloads.
>
>   Barry
>
>
> On Oct 29, 2013, at 1:59 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>
>> On Tue, 29 Oct 2013, Jed Brown wrote:
>>
>>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>>>  Or simpler just have the ?with-clean nuke external packages; makes
>>>>  life easy.  By "store the tarballs in a common place? and SHA1 crap
>>>>  you are making the system more complicated to understand and
>>>>  maintain.
>>>
>>> People will complain when they have to download the same tarball many
>>> times.  But I don't especially care as long as the builds are done
>>> inside $PETSC_ARCH instead of in a common place.  (This is also useful
>>> when building multiple configurations of PETSc in parallel.)
>>
>> There is also the issue with git repos to deal with. [presumably the
>> above logic would be slightly different than the tarballs]
>>
>> We [Jed and I ] also discussed having git repos and corresponding
>> tarballs match - and caching tarballs locally for unreliable external
>> sites. And then using SHA as a way of versioning to eliminate most
>> cases where with-clean would be needed.
>>
>> Just a note: all these issues are primarily with git users - not
>> petsc-release/tarball users.
>>
>> Satish
>



------------------------------

Message: 7
Date: Tue, 29 Oct 2013 13:12:30 -0600
From: Jed Brown <jedbrown at mcs.anl.gov>
To: Barry Smith <bsmith at mcs.anl.gov>
Cc: For users of the development version of PETSc
        <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on
        /usr/local/include and enabled but header files from this dir   are not
        added to build path
Message-ID: <8761sfuc0x.fsf at mcs.anl.gov>
Content-Type: text/plain; charset="utf-8"

Barry Smith <bsmith at mcs.anl.gov> writes:
>    Besides us, hardly anyone uses more than 2 PETSC_ARCH!

And here I have 60 on one machine.  It might be time to clean up a
little.

>    So how about just moving externalpackages into $PETSC_ARCH and
>    don?t build some elaborate scheme that reuses tar balls for a tiny
>    number of people.  In other words a clean truly means clean and
>    gets new tar balls.

That sounds good to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/248da1e6/attachment-0001.pgp>

------------------------------

Message: 8
Date: Tue, 29 Oct 2013 15:15:41 -0400
From: Aron Ahmadia <aron at ahmadia.net>
To: Jed Brown <jedbrown at mcs.anl.gov>
Cc: For users of the development version of PETSc
        <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on
        /usr/local/include and enabled but header files from this dir are not
        added to build path
Message-ID:
        <CAPhiW4gmZwD-yrSM8W3nd7Jeww7F23TGPty0ae8kRyj_bN+idw at mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

> >    So how about just moving externalpackages into $PETSC_ARCH and
> >    don?t build some elaborate scheme that reuses tar balls for a tiny
> >    number of people.  In other words a clean truly means clean and
> >    gets new tar balls.
>
> That sounds good to me.
>

I don't expect (or really want) any more complexity out of PETSc.  +1 from
here.

A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/2b76fc4c/attachment-0001.html>

------------------------------

Message: 9
Date: Tue, 29 Oct 2013 14:16:14 -0500 (CDT)
From: Satish Balay <balay at mcs.anl.gov>
To: Barry Smith <bsmith at mcs.anl.gov>
Cc: petsc-dev <petsc-dev at mcs.anl.gov>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected        on
        /usr/local/include and enabled but header files from this       dir     are not
        added to build path
Message-ID: <alpine.LFD.2.03.1310291412460.3576 at mcs.anl.gov>
Content-Type: text/plain; charset="windows-1252"

I mistated one thing.

The git-url usage in pacakge.py spills over to tarball users aswell.

Now to have consistant tarballs wrt git repo - we have to migrate all
tarball urls to tarballs from the git repo hosting site. [and not host
at ftp.mcs.anl.gov]

But this is unreliable [the last I checked with elemental at github -
git failed frequently - but it was giving out taballs more reliably]

satish

On Tue, 29 Oct 2013, Barry Smith wrote:

>
>    Just because you can do it doesn?t mean you should do it.
>
>    Barry
>
> On Oct 29, 2013, at 2:07 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> >
> >  It is not worthy any additional logic in the already messing configure process to save a few downloads.
> >
> >   Barry
> >
> >
> > On Oct 29, 2013, at 1:59 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> >
> >> On Tue, 29 Oct 2013, Jed Brown wrote:
> >>
> >>> Barry Smith <bsmith at mcs.anl.gov> writes:
> >>>>  Or simpler just have the ?with-clean nuke external packages; makes
> >>>>  life easy.  By "store the tarballs in a common place? and SHA1 crap
> >>>>  you are making the system more complicated to understand and
> >>>>  maintain.
> >>>
> >>> People will complain when they have to download the same tarball many
> >>> times.  But I don't especially care as long as the builds are done
> >>> inside $PETSC_ARCH instead of in a common place.  (This is also useful
> >>> when building multiple configurations of PETSc in parallel.)
> >>
> >> There is also the issue with git repos to deal with. [presumably the
> >> above logic would be slightly different than the tarballs]
> >>
> >> We [Jed and I ] also discussed having git repos and corresponding
> >> tarballs match - and caching tarballs locally for unreliable external
> >> sites. And then using SHA as a way of versioning to eliminate most
> >> cases where with-clean would be needed.
> >>
> >> Just a note: all these issues are primarily with git users - not
> >> petsc-release/tarball users.
> >>
> >> Satish
> >
>
>

------------------------------

_______________________________________________
petsc-dev mailing list
petsc-dev at mcs.anl.gov
https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev


End of petsc-dev Digest, Vol 58, Issue 61
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/1a5f5501/attachment.html>


More information about the petsc-dev mailing list