[Users] ExternalLibraries without tarballs
Frank Loeffler
knarf at cct.lsu.edu
Thu Aug 8 19:46:11 CDT 2013
Hi,
On Thu, Aug 08, 2013 at 08:34:09PM -0400, Erik Schnetter wrote:
> ExternalLibraries thorns containing tarballs can be very large, in
> particular if the history of the thorn grows and contains multiple
> tarballs.
It only really grows (for the user) if a revision control system is used
that stores all of the history on the client side - something a user
wouldn't be interested in usually, for external libraries. git is one of
these. A counter example is Subversion, which wouldn't have that
problem, and all external libraries are currently stored in Subversion.
> Other advantages of storing source trees are:
> - this is what we do for every thorn, so why not for ExternalLibraries (d'oh)
External libraries are not like other thorns. Even when present in a
thornlist, the source of external libraries might not be used in the
end if a system versions is detected and usable, but it needs to be
present. Decompressing all external libraries would lead to even more
small files, which especially on clusters could get you into trouble.
Of course you need to have the inodes when you compile it anyway, but
again: you might not need to (compile it), and most of these are deleted
again after the build.
> - one can easily look at the source code of an external library
> - no need to untar and later delete the source tree while building
For a regular user this happens automagically, but I agree that this
would be a plus for the maintainer of that thorn.
> - no need to apply patches -- the changes can be made directly in the source tree
I don't think this would be good. I would like to see which changes the
Cactus thorn did compared to the vanilla version. Also, from a
developers standpoint maintaining patches is far easier for upgrading
the library than recreating and applying patches every time for an
upgrade by hand. I strongly urge everyone to keep the vanilla version
clearly separated from Cactus-specific changes.
> In my opinion, this is the way to go. I am currently setting up a new
> repository of ExternalLibraries/Boost in this way. (Obviously, it is
> not possible to keep the current repository, since its history is
> already at 406 MB.)
I don't really see a problem with the current setup. Even the boost svn
checkout shouldn't be that large. The problem you describe really only
applies for a git repository. We don't need to use git. We even don't
use git for the external libraries.
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20130808/1cdadfbb/attachment.bin
More information about the Users
mailing list