Hi James,
thanks for your thoughts on abstraction of common tasks.
For most of these things we have now patches in bitbucket.
Similar recipes could be:
autoconf: default to configure; make; make install, allow providing
configuration options
On Aug 26, 2013, at 11:59 AM, James Taylor wrote:
On Mon, Aug 26, 2013 at 11:48 AM, John Chilton chil...@msi.umn.edu wrote:
I think it is interesting that there was push back on providing
infrastructure (tool actions) for obtaining CBL from github and
performing installs based on it because
Before I went on that tangent, I should have said I of course agree
with 100% of what James said in the original e-mail on this thread.
For what it is worth, I believe the higher-level constructs he
outlined are essential to the long term adoption of the tool shed.
On Tue, Aug 27, 2013 at 1:59
All,
I've been seeing some examples of tool_depedencies.xml come across of
the list, and I'm wondering if there are ways that it can be
simplified. When we were first defining these features, we talked
about having high level recipes for certain types of installs. This
could greatly simplify
James, et. al.
I think it is interesting that there was push back on providing
infrastructure (tool actions) for obtaining CBL from github and
performing installs based on it because it was not in the tool shed
and therefore less reproducible, but the team believes infrastructure
should be put in
On Mon, Aug 26, 2013 at 11:48 AM, John Chilton chil...@msi.umn.edu wrote:
I think it is interesting that there was push back on providing
infrastructure (tool actions) for obtaining CBL from github and
performing installs based on it because it was not in the tool shed
and therefore less
