[petsc-dev] confusing download instructions

[Satish Balay]

Yes - git usage has these extra requirements.

Perhaps its possible to make sowing more portable [I don't know]. But
it still pushes these requirements to the user..

Satish

On Fri, 28 Jun 2013, Barry Smith wrote:

> 
>    Satish,
> 
>     What about Windows issues with the git version? Doesn't sowing requiring gnu compilers which users who are using microsoft/intel compilers for PETSc won't have and hence cannot make fortran stubs? Can we make sowing more portable and build able by windows compilers?
> 
>    Barry
> 
> On Jun 28, 2013, at 12:58 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 
> > Barry Smith <bsmith at mcs.anl.gov> writes:
> > 
> >>    We should say
> >> 
> >> PETSc Release Version 3.4
> >> 
> >> 	• Prefered method: git clone -b maint https://bitbucket.org/petsc/petsc petsc (updates may be obtained via git pull && make)
> >> 	• petsc-3.4.1.tar.gz - full distribution (including most current patches) with documentation
> >> 	• petsc-lite-3.4.1.tar.gz - smaller version with no documentation (all documentation may be accessed on line)
> >> 	
> >> That is, by default we want people to get PETSc releases via git. 
> > 
> > Fine with me.
> > 
> >> One big issues is documentation? Is it possible to build on all
> >> systems and how long does it take? Sometimes hours! 
> > 
> > Longer-term, we should make this faster and more portable.  In the past,
> > we've talked about doing it with Python, which I think is a good idea,
> > but changing languages is not the reason for the speed problem.  Do you
> > know why sowing is so slow?  (I haven't profiled, but some things take
> > forever.)
> > 
> >> So people who use git don't get documentation unless they do an extra
> >> command, is that ok? Could we have the docs in another tar ball that
> >> the user just brings in "on top of" the git repository (maybe even a
> >> make command to get the tar ball and untar in the right place?)
> > 
> > That sounds reasonable.
> 
>