- `_expand_virtual_packages` now gets a candidate list and will try
all the candidates.
- Good news: If the first virtual in the list conflicts with something else in
the spec, we'll keep trying until we find a good one.
- Bad news: Only looks as far as the next normalize(); can't see
conflicts further ahead than that if they're inevitable
some other virtual expansion.
- Refactor `concretize.py` to keep all the nasty spec graph stitching in
`spec.py`. This is more similar to before externals support.
- `concretize.py` now just returns a list of candidates sorted by
ABI compatibility to `_expand_virtual_packages`, and `spec.py`
handles testing the candidates.
- Refactor the way external paths are handled in `config.py` and `concretize.py`:
- previously, `spec_externals` returned spec/path pairs. Now it
returns specs with `external` set. Makes code in `concretize.py`
more natural.
- Shouldn't call .package from within things like normalize() and
concretize() beacuse spec may be inconsistent.
- Add `.package_class` property so that we can get at package metadata
without constructing a Package with a Spec.
- should be faster than `.package` was, anyway. Use where possible.
not change the behavior for existing packages that subclass from
spack.Package.
If a package subclasses spack.StagedPackage instead of spack.Package,
the install() phase (run inside a forked process) is now separated
into sub-stages:
a) spconfig: Generate a script spconfig.py that will configure the
package (eg by running CMake or ./configure) This is for use if
the user wishes to build externally from Spack. Therefore, the
Spack compiler wrappers are NOT used here. Currently, that
means that RPATH support is up to the user.
b) configure: Configure the project (eg: runs configure, CMake,
etc). This will configure it for use within Spack, using the
Spack wrapper.
c) build: eg: "make"
d) install: eg: "install"
If one chooses to use StagedPackage instead of Package, then one must
implement each of the install sub-stages as a separate method.
StagedPackage.install() then calls each of the sub-stages as
appropriate.
StagedPackage can be configured to only run certain sub-stages. This
is done by setting the optional kwarg install_phases when calling
do_install(). Setting install_phases() ONLY has an effect on
StagedPackage, not on any existing packages. By default,
install_phases is set to make StagedPackage run the same stages that
are normally run for any package: configure, build, install (and NOT
spconfig).
The ability for Spack to run stages selectively for StagedPackage
instances will enable new functionality. For example, explicit
CMake/Autotools helpers that allow Spack to help configure a user's
project without fetching, building or installing it.
-------------
One implementation of StagedPackage is provided, CMakePackage. This
has the following advantage for CMake-based projects over using the
standard Package class:
a) By separating out the phases, it enables future new functionality
for packages that use it.
b) It provides an implementation of intall_spconfig(), which will
help users configure their CMake-based projects.
CMakePackage expects users to implement configure_args() and
configure_env(). These methods provide the package-specific arguments
and environment needed to properly configure the package. They are
placed in separated functions because they are used in both the
spconfig and configure stages.
TODO:
1. Generate spconfig.py scripts that are more readable. This allows
the users to understand how their project is configured.
2. Provide a practical way for the user to ACCESS the spconfig stage
without building the project through Spack.
3. The CMAKE_TRANSITIVE_INCLUDE_PATH stuff needs to be reworked; it
should be considered provisional for now.
4. User of Autotools might wish to make a similar ConfigurePackage
subclass of StagedPackage.
---------------
One package using CMakePackage is introduced. See ibmisc/package.py.
- Move `Spec.__cmp__` out of spec, into concretize as `cmp_specs`.
- `Spec.__cmp__` was never called (except explicitly) due to rich
comparison operators from `key_ordering`
- Refactor `_find_other_spec` to free function `find_spec`. Add a test
for it to make sure it works.
- Had attempted to add more functionality by assigning different
meanign None, True, and False values "keep_stage" (where False was
"always delete").
- Turns out that's not really worth the complexity. Having the third
"always delete" sense is hardly ever useful but makes the code hard
to understand.
- Fix bug introduced during merge of stage refactor.
- install prefix was not created before build_environment.fork()
- build_environment.fork() calls setup_dependent_environment
- python's setup_dependent_environment can inadvertently create
the install prefix before directory_layout expects it.
- Clean up Package.do_install:
- simplify control flow: parent process now entirely responsible for
creating/destroying the install prefix. cleanup is now in one place.
- Hoisting cleanup out of the child improves nesting of try/catch in
`real_work`.
- `real_work` renamed to `build_process`
- Allows skipping the expand step for downloads.
- Fixed stage so that it knows expansion didn't fail when there is a
no-expand URLFetchStrategy.
- Updated docs to reflect new option, and provided an example.
- package.py uses context manager more effectively.
- Stage.__init__ has easier to understand method signature now.
- keep can be used to override the default behavior either to keep
the stage ALL the time or to delete the stage ALL the time.
- This reverts commit c5d9ee8924.
- merged too soon before
- reverting and fixing bugs now.
Conflicts:
lib/spack/spack/mirror.py
lib/spack/spack/package.py
This does several things:
- Add `sbang`: a script to run scripts with long shebang lines.
- Documentation for `sbang` is in `bin/sbang`.
- Add an `sbang` hook that filters the `bin` directory after install
and modifies any scripts wtih shebangs that are too long to use
`sbang` instead.
- `sbang` is at the top level, so it should be runnable (not much we
can do if spack itself is too deep for shebang)
- `sbang`, when used as the interpreter, runs the *second* shebang
line it finds in a script.
- shoud fix issues with too long shebang paths.
