| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
DESTDIR support. Simplify. Bump revision.
|
|
|
|
|
|
- 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.
|
|
on packages that are affected by the switch from the openssl 0.9.7
branch to the 0.9.8 branch. ok jlam@
|
|
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.
|
