Conversation
|
Actually, hold off on this, I might need to build with an old version of JasPer anyway: EDIT: As I feared, GDAL explicitly requires that old hacked version of JasPer. I'm going to have to make this a multi-build system package. |
|
Maybe we should take another look at supporting multiple build systems per package. I'm not completely sold on this, but the number of packages that I know of and that changed their build system is >2 now... This is one of the reasons why I'm yet to add nest to upstream spack... |
|
Testing this with an older version of CMake and now I'm running into problems: EDIT: I successfully installed JasPer with a newer version of CMake, so I think |
There are exactly 7 out of 2693 packages in Spack that use multiple build systems:
I'm not sure how easy it would be to add builtin support for this. I'm sure it's doable, but would probably require some refactoring. I guess it depends on how much work it would be. |
|
@adamjstewart Look at |
|
@alalazo If I use a file instead of a URL, does the patch go with the dependent package or with the parent package? EDIT: Looks like it checks in the GDAL directory, that makes sense. |
|
This is now ready to merge. Successfully installed both versions with Clang 9.0.0 on macOS 10.13.4. All unit tests passed. |
* Add JasPer 2.0.14 * Remove no longer necessary patch * Explicitly disable generation of documentation * Re-add support for JasPer 1.900.1, add GDAL patch * Remove GDAL patch
3 participants
I ended up dropping the old version of JasPer because
.zipto.tar.gzIf someone really needs it, I can add support for it, but if not, I'd rather leave it out. It increases the complexity of the package too much.
P.S. Successfully installed on macOS 10.13.4 with Clang 9.0.0. Passed all of its own tests.