[petsc-dev] elemental in nightly builds with g++-4.6

[Satish Balay]

On Wed, 9 Oct 2013, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > in this case the url would be https://github.com/elemental/Elemental/archive/89e7ddc52db68dc5a3f2635733293d7349dbd518.tar.gz
> 
> Will we have to name it to match elemental* ?

Its inheriting the repo name - 'Elemental*' - so if are mixing repos
and tarballs - perhaps they both need to have the same prefix..

And I see one more issue.

configure should use url provided by user and override whats in
package.py. But with giturl - its using giturl always - and ignoring user specified url.

--download-elemental=https://github.com/elemental/Elemental/archive/89e7ddc52db68dc5a3f2635733293d7349dbd518.tar.gz

> >> Those fallback tarballs are currently a maintenance issue.  Can we automate it?
> >
> > Hm - currently updating the url in package.py is a manual process. so
> > updating ftp.mcs would be done at the same time.
> >
> > But if we want some kind of automatic fallback for all urls - perhaps we
> > can setup a squid-proxy cache at mcs - and configure always uses that?
> > [maybe it won't work for all cases..]
> 
> Yeah, something like that could work.  It would be enough to cache
> things under either the SHA1 or the "upstream" URL.

I'm not sure how squid works. presumably it has some comparision algorithom to
decide to cache or redownload.

But if we have to keep track of SHA1 - then it would be manual process
[of updating package.py? - so manually placing tarballs at ftp.mcs is
not a big deal?]

Also - I'm  not sure how sha1 would work in this scheme..

satish