spack/var/spack/repos/builtin/packages/lua-luajit/package.py

63 lines
2.1 KiB
Python
Raw Normal View History

# Copyright 2013-2023 Lawrence Livermore National Security, LLC and other
# Spack Project Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)
import os
from spack.package import *
from spack.pkg.builtin.lua import LuaImplPackage
2016-08-10 16:50:00 +08:00
class LuaLuajit(LuaImplPackage):
"""Flast flexible JITed lua"""
start of work to add spack audit packages-https checker (#25670) This PR will add a new audit, specifically for spack package homepage urls (and eventually other kinds I suspect) to see if there is an http address that can be changed to https. Usage is as follows: ```bash $ spack audit packages-https <package> ``` And in list view: ```bash $ spack audit list generic: Generic checks relying on global variables configs: Sanity checks on compilers.yaml Sanity checks on packages.yaml packages: Sanity checks on specs used in directives packages-https: Sanity checks on https checks of package urls, etc. ``` I think it would be unwise to include with packages, because when run for all, since we do requests it takes a long time. I also like the idea of more well scoped checks - likely there will be other addresses for http/https within a package that we eventually check. For now, there are two error cases - one is when an https url is tried but there is some SSL error (or other error that means we cannot update to https): ```bash $ spack audit packages-https zoltan PKG-HTTPS-DIRECTIVES: 1 issue found 1. Error with attempting https for "zoltan": <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'www.cs.sandia.gov'. (_ssl.c:1125)> ``` This is either not fixable, or could be fixed with a change to the url or (better) contacting the site owners to ask about some certificate or similar. The second case is when there is an http that needs to be https, which is a huge issue now, but hopefully not after this spack PR. ```bash $ spack audit packages-https xman Package "xman" uses http but has a valid https endpoint. ``` And then when a package is fixed: ```bash $ spack audit packages-https zlib PKG-HTTPS-DIRECTIVES: 0 issues found. ``` And that's mostly it. :) Signed-off-by: vsoch <vsoch@users.noreply.github.com> Co-authored-by: vsoch <vsoch@users.noreply.github.com>
2021-09-02 14:46:27 +08:00
homepage = "https://www.luajit.org"
url = "https://luajit.org/download/LuaJIT-2.0.5.tar.gz"
version(
"2.1.0-beta3", sha256="1ad2e34b111c802f9d0cdf019e986909123237a28c746b21295b63c9e785d9c3"
)
version(
"2.0.5",
sha256="874b1f8297c697821f561f9b73b57ffd419ed8f4278c82e05b48806d30c1e979",
preferred=True,
)
version("2.0.4", sha256="620fa4eb12375021bef6e4f237cbd2dd5d49e56beb414bee052c746beef1807d")
conflicts("@:2.0.5", when="target=aarch64:")
variant(
"lualinks",
default=True,
description="add symlinks to make lua-luajit a drop-in lua replacement",
)
Cherry-picking virtual dependencies (#35322) This PR makes it possible to select only a subset of virtual dependencies from a spec that _may_ provide more. To select providers, a syntax to specify edge attributes is introduced: ``` hdf5 ^[virtuals=mpi] mpich ``` With that syntax we can concretize specs like: ```console $ spack spec strumpack ^[virtuals=mpi] intel-parallel-studio+mkl ^[virtuals=lapack] openblas ``` On `develop` this would currently fail with: ```console $ spack spec strumpack ^intel-parallel-studio+mkl ^openblas ==> Error: Spec cannot include multiple providers for virtual 'blas' Requested 'intel-parallel-studio' and 'openblas' ``` In package recipes, virtual specs that are declared in the same `provides` directive need to be provided _together_. This means that e.g. `openblas`, which has: ```python provides("blas", "lapack") ``` needs to provide both `lapack` and `blas` when requested to provide at least one of them. ## Additional notes This capability is needed to model compilers. Assuming that languages are treated like virtual dependencies, we might want e.g. to use LLVM to compile C/C++ and Gnu GCC to compile Fortran. This can be accomplished by the following[^1]: ``` hdf5 ^[virtuals=c,cxx] llvm ^[virtuals=fortran] gcc ``` [^1]: We plan to add some syntactic sugar around this syntax, and reuse the `%` sigil to avoid having a lot of boilerplate around compilers. Modifications: - [x] Add syntax to interact with edge attributes from spec literals - [x] Add concretization logic to be able to cherry-pick virtual dependencies - [x] Extend semantic of the `provides` directive to express when virtuals need to be provided together - [x] Add unit-tests and documentation
2023-11-02 14:35:23 +08:00
provides("luajit", "lua-lang@5.1", when="+lualinks")
lua_version_override = "5.1"
conflicts("platform=darwin", msg="luajit not supported on MacOS, see lua-luajit-openresty")
@run_after("install")
def install_links(self):
self.symlink_luajit()
@property
def headers(self):
hdrs = find_headers("luajit", self.prefix.include, recursive=True)
hdrs.directories = os.path.dirname(hdrs[0])
return hdrs or None
def edit(self, spec, prefix):
makefile = FileFilter("Makefile")
makefile.filter("PREFIX= .*", "PREFIX = {0}".format(prefix))
src_makefile = FileFilter(join_path("src", "Makefile"))
src_makefile.filter("^DEFAULT_CC = .*", "DEFAULT_CC = {0}".format(spack_cc))
src_makefile.filter(
"^DYNAMIC_CC = .*", "DYNAMIC_CC = $(CC) {0}".format(self.compiler.cc_pic_flag)
)
2022-06-04 20:44:45 +08:00
# Linking with the C++ compiler is a dirty hack to deal with the fact
# that unwinding symbols are not included by libc, this is necessary
# on some platforms for the final link stage to work
src_makefile.filter("^TARGET_LD = .*", "TARGET_LD = {0}".format(spack_cxx))