Telcon: 2015 06 18

Participants

Packages: Better vim build, the_silver_searcher, tmuxinator, Ruby improvement, pyelftools
Changes for faster git fetching (shallow clone, fetch all tags, etc. -- see cfb8836, b8aeab0)

v0.9 is coming along, but I have not had enough time to work on the final round of bug fixes with students arriving for the summer.
Should get some time to work on this over the weekend.
We should also have some more developer support soon -- looking for developers for a tool productization team at LLNL (anyone interested?)

Issues with some packages' source forge URLs.
- See Bug #59.
- Should the solution be to modify the URL or to use different links?
- Not sure if my suggestion to Tom there is valid for all SF projects.

Florent makes a really good point about complexity of dealing with cross-cutting variants right now.
- Can get combinatoric with many different dependencies.
- No way to specify mutually exclusive options easily.

Clang plugins might be best handled this way (some don't support a standalone build well)
Matt Legendre suggests that a better option would be a special type of build dependency:
- Add a depends_include or depends_build('dep', include=True) directive
- Instead of installing the dep in its own prefix, it untars it in the package source at build time.
- Dependency is recorded in the package DAG (solving the versioning problem), but doesn't actually depend on another install prefix (sort of like static linking)
- What happens when you have this:
  - A depends on B and C, B is an "included" build dependency
  - C depends on B normally
- Should be possible to have two B's in the DAG, right?
  - Should they be required to have the same version?
    - Simpler and more consistent w/current model if they do.
    - B can occur once in the DAG if they do, but would still be included in the build of A
    - libs for B may exist in A.prefix.lib and B.prefix.lib in this scenario, but shouldn't conflict
      - unless A patches them... sigh.
  - Can probably hold off on this special case until it arises, and require consistency until then.

Nightly build will fail to find a command from a dependency.
Next morning, things "sort of" work -- package builds again and sees possibly improperly installed dependency.
Thought it was a filesystem race
Turns out Mike was trying to do this:

cmake = which("%s/bin" % spec.prefix)

but that won't find cmake.

cmake = Executable("%s/bin/cmake" % spec['cmake'].prefix)
cmake = which('cmake')

Odd, though is that the builtin cmake Executable object doesn't find cmake in a dependency's bin directory.
- Looked at build_environment.py, and cmake is set up there using which
- This will search too early, so if you depend on cmake it won't find it (oops).
- FIX: build_environment should use Executable instead of which to set up cmake.
  - Spack really needs a better notion of build dependencies
  - Needs a way to discover them automatically (e.g. system cmake) OR to build them if they're not present.
    - Make this a TODO for 1.0 -- we've talked about stronger notion of build deps before.
why doesn't Spack's which work when you pass it an absolute path?
- Command-line which works with absolute paths.

e.g., bin/cmake executable from the cmake package should be used by dependents.
solution thus far is for dependent to call which('cmake')
OR parent package can do this:

def setup_dependent_environment(self, module, spec, dep_spec):
   module.cmake = Executable(join_path(self.prefix.bin, 'cmake'))

In this case, cmake is injected into the dependent's module scope, can be used like configure, cmake, etc.
Might be better to allow things to be passed on the spec so that dependents can do this:

def install(self, spec, prefix):
  spec['cmake'].cmake

Both of these options have namespace pollution issues
- either the dependent module namespace or the spec object namespace.
- Think about how to avoid that and provide clean namespaces.