spack configure/build doesn't work for all package base classes

[adamjstewart]

spack configure and spack build are designed stop at a certain phase of the package installation process for debugging purposes. However, this only works for CMakePackage, AutotoolsPackage, and PythonPackage. These 3 build systems contain separate build and install phases.

This doesn't work for MakefilePackage even though it has a build phase:

$ spack build lammps
==> Error: Package lammps has no build phase, or its build phase is not separated from install

It also doesn't work for a Package class with manually added build phases:

$ spack build qbank
==> Error: Package qbank has no build phase, or its build phase is not separated from install

See #3641 for this qbank package.

Based on the commands, it looks like we are looking for the package base class in build_systems_to_phase, a dictionary that converts the phase to the name of the function. If the base class isn't in this dictionary, it crashes, even if the package has a build phase defined.

@alalazo

[alalazo]

MakefilePackage was not added to the dictionary, so solving this is just a matter of adding the entry.

For things like qbank, which use a custom build system but can be divided into different phases, we can decide on a convention and inspect the package. The convention can be as simple as checking that configure in phases is True (and then stopping at configure). If you think this can work I'll write a PR to solve the issue.

[adamjstewart]

Works for me! Honestly, I'm wondering if we should just rename the cmake phase in CMakePackage to configure. That's what every other build system calls it. configure isn't just an executable that comes with Autotools, it's also a verb that describes what cmake is doing. But then we would have to consider renaming the edit phase of MakefilePackage to configure, which is a bit different. Probably best to keep that one the same. The alternative to renaming things is to tell spack configure and spack build to search for a cmake or configure phase. I'm fine with either solution.

[tgamblin]

Why not add a configure method in CMakePackage that just calls cmake()? Then you can override either and it'll work, and spack configure will call whichever one is implemented. Same for configure_args.

I'd need to think about what happens when you inherit from both AutotoolsPackage and CMakePackage and override both conditionally. It would be nice if packages like dyninst whose build systems have changed over time would work in that scenario. Then again, renaming the cmake to configure makes that work. Could one inherit from all three and decorate with @when to pick make, cmake, or autotools by version?

[alalazo]

@tgamblin I'll try to have a look at dyninst at take that as a use case.

[junghans]

lammps got switched to CMake in effba3c.

[adrienbernede]

Hello @alalazo,

I am having the same issue: trying to define an additional phase in a simple "Package", which behaves like a configure phase when using spack configure.

Did you come up with a way to do that ?

Thanks,

PS:
By the way, could we imagine a mechanism to stop a package "installation" at any phase mentioned in that package ?
Let’s say I define my-package with:
phases=['init','conf','build','install']
And I could then do:
spack stop-at init my-package