Commit graph

7 commits

Author SHA1 Message Date
joerg
2d1ba244e9 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 19:23:50 +00:00
joerg
3abd2d8fbf Don't use text relocations, link against shared libcrypto.
DESTDIR support. Simplify. Bump revision.
2009-02-11 23:25:59 +00:00
tnn
97822f1b10 Fix DEPENDS for Python 2.5. 2008-04-25 22:30:47 +00:00
tnn
29075003c4 Don't hardcode PYPKGPREFIX in bl3.mk 2008-04-25 22:16:20 +00:00
joerg
a77e7015fe Update PYTHON_VERSIONS_COMPATIBLE
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
2008-04-25 20:39:06 +00:00
tnn
ad6ceadd25 Per the process outlined in revbump(1), perform a recursive revbump
on packages that are affected by the switch from the openssl 0.9.7
branch to the 0.9.8 branch. ok jlam@
2008-01-18 05:06:18 +00:00
agc
72f70f2fc6 Initial import of py-SSLCrypto-0.1.1 into the Packages Collection.
SSLCrypto is a package for Python that dramatically eases the task of
	adding encryption to Python programs.

	It provides a unified API that is almost totally compatible with that
	of ezPyCrypto, except that it takes advantage of the OpenSSL Crypto
	Library to deliver massive improvements in speed and security.

	After using ezPyCrypto myself, I found that while it performed ok with
	smaller public key sizes, it proved impossibly slow with larger keys.
	This slowness, resulting from non-optimal code in its backend (the
	Python Cryptography Toolkit) meant that on a 1.5 GHz Athlon XP, it was
	taking several minutes to generate 4096-bit keys.  Completely
	unacceptable if you need real security.

	Performance is absolutely critical for an encryption API.  If slowness
	deters people from using adequate-sized keys, security will be
	severely compromised, almost to the extent that there's little point
	in using encryption in the first place.
2007-05-05 00:03:54 +00:00