fenics team mailing list archive
-
fenics team
-
Mailing list archive
-
Message #02086
Re: CMake 2.8.11: ExternalData
On 09/04/13 20:14, Anders Logg wrote:
> On Tue, Apr 09, 2013 at 06:26:44PM +0200, Nico Schlömer wrote:
>> FYI, CMake 2.8.11 (rc2 just released) will contain support for
>> ExternalData (aka those meshes):
>>
>> Introduced ExternalData Module
>> * Keep source trees lightweight by storing data separately
>> * Reference data unambiguously from source tree by content hash
>> * Fetch on-demand during build from local or remote resources
>>
>> https://github.com/Kitware/CMake/blob/master/Modules/ExternalData.cmake
>
> Sounds good to me. It would require using CMake for FFC, since we have
> a similar problem there (storing the references used for regression
> tests).
I think this could be a good option for DOLFIN meshes as Nico suggests.
> Another option would be git submodules. Florian suggested this to me
> earlier.
That's what I think would have been a good option for outsourcing the
references. They are by far the biggest chunk of the FFC repository (in
size) and only developers care about them, while everyone else has a
much larger repository to clone which also takes up considerable disk
space (51M at the moment).
Having the references be a submodule means the
test/regression/references directory would be a pointer to a particular
revision (SHA1) of another repository. Each FFC revision would have a
particular revision of the ffc-references repository associated with it,
so there is no ambiguity. It would also have the advantage that if we
would completely redesign the FFC testing infrastructure and wouldn't
need the references any more we could simply get rid of the submodule
and wouldn't have to carry around their burden in history forever.
There's a few caveats though:
1) If we were doing this now we would need to rewrite the history again,
completely strip the references folder and replace it by the submodule.
2) Syncing a git repository over to launchpad for automatic package
building with the bzr builder is not possible if the repository has
*ever* included a submodule in its history [1], but there are
workarounds [2] (which can't be run as a BitBucket hook however).
3) Pull requests would be a bit more tricky since ffc-references and ffc
would have to be always merged as a pair. For core developers with push
access to the repositories this could probably be handled with a
pre-commit hook.
[1]: https://bugs.launchpad.net/bzr-git/+bug/402814
[2]:
https://bazaar.launchpad.net/~videolan/vlc/manual-bzr-import/view/head:/manual-bzr-import
Florian
> --
> Anders
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
References