(originally from @cbeck88 on travis-ci/packer-templates#297 (comment))
Hi, I saw a link to here from travis-ci/travis-ci#6300
At the risk of suggesting something without fully understanding it, let me ask a question about travis "community cookbooks" which I saw here: https://github.com/travis-ci/travis-cookbooks/tree/master/community-cookbooks
It appears to me that some languages have extra cookbooks here, like java, php, and I dimly remember ghc (haskell) being here also when I looked at it first, although I don't see that now.
Would it be helpful if there were community-maintained cookbooks for various versions of gcc / clang? The idea would be to follow gcc / clang dev instructions to build from source, and not link to system standard library like e.g. debian packages do, but an independent instance in home directory. Getting a C++11 conforming standard library is one of the biggest ticket items I would say for C++ support.
Some aspects of how travis-ci works that aren't clear to me:
- Relation between image and the cookbooks -- presumably some cookbooks get pre-installed in the images, and others are meant to run afterwards as part of your build. Is this correct?
- How are these community-maintained cookbooks invoked in an actual build? Do they get triggered by
language: python
,language: java
, etc.? - Is it plausible that a community-maintained cookbook could become part of an image template, or do you only want real debian packages to become part of an image template?
Maybe. My strong preference is to import as little as possible into the
./community-cookbooks
tree.If the goal is to have toolchains prefixed at or under
$HOME
that are not linked to the system stdlib, then I think this may be a reasonable fit for the way we build and "install" things like erlang, python, and php versions into$HOME
. I can explain further in an additional file on this gist. Interested in pursuing that?