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

16 lines
407 B
Makefile
Raw Normal View History

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
# $NetBSD: buildlink3.mk,v 1.2 2009/03/20 19:25:21 joerg 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
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