On Oct 29, 2013, at 3:39 PM, Åsmund Ervik <[email protected]> wrote:
> 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
Sure and this is fine. My point was that burden of dealing with a
./configure option of —with-clean wiping out the tar balls of external packages
is minor because it affects so few people and only when they make a completely
clean install which for most people is very uncommon.
If you guys do completely clean installs for every test that uses a bunch of
external packages than I recommend getting all the external package tar balls
over once and using the —download-package=locationoftarball option in your
tests.
Barry
>
>
> Sent from my VT-102
>
> [email protected] skrev:
> Send petsc-dev mailing list submissions to
> [email protected]
>
> 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
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> 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 <[email protected]>
> To: Jed Brown <[email protected]>
> Cc: For users of the development version of PETSc
> <[email protected]>
> 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: <[email protected]>
> Content-Type: text/plain; charset=windows-1252
>
>
> On Oct 29, 2013, at 9:04 AM, Jed Brown <[email protected]> wrote:
>
> > Barry Smith <[email protected]> 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 <[email protected]>
> To: Barry Smith <[email protected]>
> Cc: For users of the development version of PETSc
> <[email protected]>
> 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: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> Barry Smith <[email protected]> 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 <[email protected]>
> To: Jed Brown <[email protected]>
> Cc: For users of the development version of PETSc
> <[email protected]>
> 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: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, 29 Oct 2013, Jed Brown wrote:
>
> > Barry Smith <[email protected]> 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 <[email protected]>
> To: Jed Brown <[email protected]>
> Cc: For users of the development version of PETSc
> <[email protected]>
> 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: <[email protected]>
> Content-Type: text/plain; charset=windows-1252
>
>
> On Oct 29, 2013, at 1:51 PM, Jed Brown <[email protected]> wrote:
>
> > Barry Smith <[email protected]> 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 <[email protected]>
> To: petsc-dev <[email protected]>
> 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: <[email protected]>
> 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 <[email protected]> wrote:
>
> > On Tue, 29 Oct 2013, Jed Brown wrote:
> >
> >> Barry Smith <[email protected]> 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 <[email protected]>
> To: petsc-dev <[email protected]>
> 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: <[email protected]>
> 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 <[email protected]> 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 <[email protected]> wrote:
> >
> >> On Tue, 29 Oct 2013, Jed Brown wrote:
> >>
> >>> Barry Smith <[email protected]> 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 <[email protected]>
> To: Barry Smith <[email protected]>
> Cc: For users of the development version of PETSc
> <[email protected]>
> 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: <[email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> Barry Smith <[email protected]> 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 <[email protected]>
> To: Jed Brown <[email protected]>
> Cc: For users of the development version of PETSc
> <[email protected]>
> 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+...@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 <[email protected]>
> To: Barry Smith <[email protected]>
> Cc: petsc-dev <[email protected]>
> 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: <[email protected]>
> 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 <[email protected]> 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 <[email protected]> wrote:
> > >
> > >> On Tue, 29 Oct 2013, Jed Brown wrote:
> > >>
> > >>> Barry Smith <[email protected]> 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
> [email protected]
> https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev
>
>
> End of petsc-dev Digest, Vol 58, Issue 61
> *****************************************
