kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/security/pakchois/buildlink3.mk

17 lines
460 B
Makefile
Raw Normal View History

Set BUILDLINK_ABI_DEPENDS correctly (with +=, not ?=) It turns out there were a lot of these.
2012-05-07 03:53:12 +02:00
# $NetBSD: buildlink3.mk,v 1.4 2012/05/07 01:53:57 dholland Exp $
Add pakchois-0.4. (upcoming new neon can use it) -- pakchois is just another PKCS#11 wrapper library. pakchois aims to provide a thin wrapper over the PKCS#11 interface. The goals are: 1) to offer a modern* object-oriented C interface wrapper for PKCS#11. 2) to not hide or abstract away any details of the PKCS#11 interface itself except where absolutely necessary. 3) to handle the details of loading DSOs 4) to allow the caller to avoid caring about where on the system PKCS#11 modules might be stored, or exactly how they are named. 5) to avoid any dependency on a particular cryptography toolkit. Existing PKCS#11 wrapper libraries solutions differ in at least one of the above goals. *: "modern" being a euphemism for not using process-global state, having a sane symbol namespace, etc.
2008-10-30 04:32:19 +01:00
Simply and speed up buildlink3.mk files and processing. This changes the buildlink3.mk files to use an include guard for the recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS, BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of enter/exit marker, which can be used to reconstruct the tree and to determine first level includes. Avoiding := for large variables (BUILDLINK_ORDER) speeds up parse time as += has linear complexity. The include guard reduces system time by avoiding reading files over and over again. For complex packages this reduces both %user and %sys time to half of the former time.
2009-03-20 20:23:50 +01:00
BUILDLINK_TREE+= pakchois
Add pakchois-0.4. (upcoming new neon can use it) -- pakchois is just another PKCS#11 wrapper library. pakchois aims to provide a thin wrapper over the PKCS#11 interface. The goals are: 1) to offer a modern* object-oriented C interface wrapper for PKCS#11. 2) to not hide or abstract away any details of the PKCS#11 interface itself except where absolutely necessary. 3) to handle the details of loading DSOs 4) to allow the caller to avoid caring about where on the system PKCS#11 modules might be stored, or exactly how they are named. 5) to avoid any dependency on a particular cryptography toolkit. Existing PKCS#11 wrapper libraries solutions differ in at least one of the above goals. *: "modern" being a euphemism for not using process-global state, having a sane symbol namespace, etc.
2008-10-30 04:32:19 +01:00
Simply and speed up buildlink3.mk files and processing. This changes the buildlink3.mk files to use an include guard for the recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS, BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of enter/exit marker, which can be used to reconstruct the tree and to determine first level includes. Avoiding := for large variables (BUILDLINK_ORDER) speeds up parse time as += has linear complexity. The include guard reduces system time by avoiding reading files over and over again. For complex packages this reduces both %user and %sys time to half of the former time.
2009-03-20 20:23:50 +01:00
.if !defined(PAKCHOIS_BUILDLINK3_MK)
PAKCHOIS_BUILDLINK3_MK:=
Add pakchois-0.4. (upcoming new neon can use it) -- pakchois is just another PKCS#11 wrapper library. pakchois aims to provide a thin wrapper over the PKCS#11 interface. The goals are: 1) to offer a modern* object-oriented C interface wrapper for PKCS#11. 2) to not hide or abstract away any details of the PKCS#11 interface itself except where absolutely necessary. 3) to handle the details of loading DSOs 4) to allow the caller to avoid caring about where on the system PKCS#11 modules might be stored, or exactly how they are named. 5) to avoid any dependency on a particular cryptography toolkit. Existing PKCS#11 wrapper libraries solutions differ in at least one of the above goals. *: "modern" being a euphemism for not using process-global state, having a sane symbol namespace, etc.
2008-10-30 04:32:19 +01:00
BUILDLINK_API_DEPENDS.pakchois+= pakchois>=0.4
Set BUILDLINK_ABI_DEPENDS correctly (with +=, not ?=) It turns out there were a lot of these.
2012-05-07 03:53:12 +02:00
BUILDLINK_ABI_DEPENDS.pakchois+= pakchois>=0.4nb1
Add pakchois-0.4. (upcoming new neon can use it) -- pakchois is just another PKCS#11 wrapper library. pakchois aims to provide a thin wrapper over the PKCS#11 interface. The goals are: 1) to offer a modern* object-oriented C interface wrapper for PKCS#11. 2) to not hide or abstract away any details of the PKCS#11 interface itself except where absolutely necessary. 3) to handle the details of loading DSOs 4) to allow the caller to avoid caring about where on the system PKCS#11 modules might be stored, or exactly how they are named. 5) to avoid any dependency on a particular cryptography toolkit. Existing PKCS#11 wrapper libraries solutions differ in at least one of the above goals. *: "modern" being a euphemism for not using process-global state, having a sane symbol namespace, etc.
2008-10-30 04:32:19 +01:00
BUILDLINK_PKGSRCDIR.pakchois?= ../../security/pakchois
.include "../../devel/gettext-lib/buildlink3.mk"
.include "../../mk/dlopen.buildlink3.mk"
Simply and speed up buildlink3.mk files and processing. This changes the buildlink3.mk files to use an include guard for the recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS, BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of enter/exit marker, which can be used to reconstruct the tree and to determine first level includes. Avoiding := for large variables (BUILDLINK_ORDER) speeds up parse time as += has linear complexity. The include guard reduces system time by avoiding reading files over and over again. For complex packages this reduces both %user and %sys time to half of the former time.
2009-03-20 20:23:50 +01:00
.endif # PAKCHOIS_BUILDLINK3_MK
Add pakchois-0.4. (upcoming new neon can use it) -- pakchois is just another PKCS#11 wrapper library. pakchois aims to provide a thin wrapper over the PKCS#11 interface. The goals are: 1) to offer a modern* object-oriented C interface wrapper for PKCS#11. 2) to not hide or abstract away any details of the PKCS#11 interface itself except where absolutely necessary. 3) to handle the details of loading DSOs 4) to allow the caller to avoid caring about where on the system PKCS#11 modules might be stored, or exactly how they are named. 5) to avoid any dependency on a particular cryptography toolkit. Existing PKCS#11 wrapper libraries solutions differ in at least one of the above goals. *: "modern" being a euphemism for not using process-global state, having a sane symbol namespace, etc.
2008-10-30 04:32:19 +01:00
Simply and speed up buildlink3.mk files and processing. This changes the buildlink3.mk files to use an include guard for the recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS, BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of enter/exit marker, which can be used to reconstruct the tree and to determine first level includes. Avoiding := for large variables (BUILDLINK_ORDER) speeds up parse time as += has linear complexity. The include guard reduces system time by avoiding reading files over and over again. For complex packages this reduces both %user and %sys time to half of the former time.
2009-03-20 20:23:50 +01:00
BUILDLINK_TREE+= -pakchois
Reference in a new issue Copy permalink