On Tue, 16 Apr 2019, Sajid Ali via petsc-users wrote: > > develop > 3.11.99 > 3.10.xx > maint (or other strings) > Just discovered this issue when trying to build with my fork of spack at [1 > <https://github.com/s-sajid-ali/spack/commit/05e499571b428f37b8cd1c7d39013e3dec08e5c8>]. > > > So, ideally each developer has to have their develop point to the branch > they want to build ? That would make communication a little confusing since > spack's develop version is some package's master and now everyone wants a > different develop so as to not let spack apply any patches for string > version sorted lower than lowest numeric version.
There is some issue filed [with PR?] regarding this with sorting order of string versions and numerical versions. This might improve in the future. But for now 'bugfix-vecduplicate-fftw-vec' will be lower than version 0.1 Also 'develop' might not be appropriate for all branches. For ex: - petsc has maint, maint-3.10 etc branches. - so if one is creating a bugfix for maint - (i.e start a branch off maint) it would be inappropriate to call it 'develop' - as it will be marked > version 3.11.99 and break some of the version comparisons. > > >Even if you change commit from 'abc' to 'def'spack won't recognize this > change and use the cached tarball. > True, but since checksum changes and the user has to constantly zip and > unzip, I personally find git cloning easier to deal with so it's just a > matter of preference. > Here you are referring to tarballs - where the sha256sum is listed. url = "http://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-3.5.3.tar.gz" version('3.11.1', 'cb627f99f7ce1540ebbbf338189f89a5f1ecf3ab3b5b0e357f9e46c209f1fb23') However - one can also say: git = "https://bitbucket.org/sajid__ali/petsc.git" version('3.11.1', commit='f3d32574624d5351549675da8733a2646265404f') Here - spack downloads the git snapshot as tarball (saves in tarball cache as petsc-3.11.1.tar.gz - and reuses it) - and there is no sha256sum listed here to check. If you change this to some-other commit (perhaps to test a fix) - spack will use the cached tarball - and not downloaded the snapshot corresponding to the changed commit. Satish