Always prefer the default version and fallback to the first entry
of PYTHON_VERSIONS_ACCEPTED, which is supported by the current
system. Also honour PYTHON_VERSIONS_ACCEPTED and _INCOMPATIBLE,
when PYTHON_VERSION_REQD is used.
all PEAR packages to php?-pear-* and all Apache packages to ap13-* or
ap2-* respectively. Add new variables to simplify the Makefile
handling. Add CONFLICTS on the old names. Reset revisions of bumped
packages. ap-php will now depend on the default Apache and PHP version.
All programs using it have an implicit option of the Apache version
as well.
OK from jlam@ and adrianp@.
only build certain modules if the platform is *not* 64-bit. Correct
the PLIST for those cases. This should fix the build on non-64bit,
non-x86 platforms, e.g. powerpc.
Changes in 0.9.4.1:
Tiny bugfix to correct a tab/space problem in the distutils
extension.
Changes in 0.9.4:
LValue Casting Is Dead
I have redesigned the code generator to eliminate the need for lvalue
casting. This means that Pyrex-generated code should now be
gcc4-compatible, although I haven't tested this. Let me know if you find
any remaining lvalue casts; they should be fairly easy to fix now.
C++ Compilable
The generated code should now be compilable as either C or C++
without errors (although there may still be warnings). However, note
that you can still only call C++ functions if they have been declared
"extern C", even if you compile the Pyrex output as C++. I hope to
introduce some C++ interface features soon.
and more.
In Changelog:
- Many bugfixes
- chicken-config was removed, "csc" providing the same functionality
- option -objc generates files in Objective-C mode
- options '-framework', '-rpath'...
...
it will live with other "check" targets run after package installation.
Get rid of SHLIB_HANDLING, whose meaning had mutated over the years
from one thing to another. Currently, it is used to basically note
whether the system's "ldd" command can be usefully run on the package's
binaries and libraries. Rename this variable to CHECK_SHLIBS_SUPPORTED
for more clarity.
CHECK_SHLIBS is now a variable set exclusively by the user in /etc/mk.conf
to note whether the check for missing run-time search paths is performed
after a package is installed. It defaults to "no" unless PKG_DEVELOPER
is set.
SPL is a powerful scripting language. It is very feature-rich (hashes, regular
expressions, objects, exceptions, built-in template language, etc. pp.) and has
a c-style syntax. The Name "SPL" is a left-recursive acronym and expands to "SPL
Programming Language". The name was meant to be pronounced as an acronym, but
I've already heard people pronouncing it "spell", which is also fine with me.
The SPL VM is a pure bytecode interpeter. Support for JIT compilation or
generating machine code for the host CPU is not planed and doesn't make much
sense for various technical reasons. The entire SPL toolchain (compiler,
assembler, virtual machine, etc) is pretty small (about 100k on x86
architectures). The additional memory usage by the applications is rather small
too. One of the more advanced VM features is the capability to dump the entire
VM state to a file and resume later. It is even possible to resume on another
machine with a different architecture.
SPL has support for loadable modules. The spl package contains already modules
for stuff such as accessing SQL databases (SQLite, Postgres, MySQL), XML (incl.
XPATH and XSLT), Terminal and File IO, Web Application development (the CGI, WSF
and W2T (Web 2.0 Toolkit) modules), SDL, Qt and much more.
SPL currently supports Linux,BSD Systems, other POSIX environments, MacOS-X
(Darwin), SGI IRIX, Cygwin and native Win32 (using MinGW).
Packaged by Raphael Langerhorst.