and not part of a normal frameworkinstall) that installs Demo and Tools
and a readme file into /Applications/MacPython-2.3/Extras. This will
give people access to the demos and tools if they instal Python through
the binary installer.
honor them). Use this when building the MacOSX binary installer to
get group-writeable files.
Ths fix works for directories and executables, not for files just yet,
because of bug #735274.
for specific platforms. Use this to add plat-mac and
plat-mac/lib-scriptpackages on MacOSX. Also tested for not having adverse
effects on Linux, and I think this code isn't used on Windows anyway.
Fixes#661521.
called python.exe but actually pass it from the main Makefile to
Mac/OSX/Makefile. This makes framework builds work again on case
sensitive filesystems. Fixes bug #677753.
compiler flags which are necessary to get a clean compile. The former is
for user-specified optimizer, debug, trace fiddling. See patch 640843.
Add /sw/lib and /sw/include to setup.py search paths on Darwin to take
advantage of fink goodies.
Add scriptsinstall target to Makefile to install certain scripts from
Tools/scripts directory.
knows about plat-mac subdirectories, and configure adds a variable
EXTRAPLATDIR. These together take care of copying Lib/plat-mac to
the destination on darwin.
Adding plat-mac is still done with a .pth file which is only created when
you do a framework build. I'm not 100% happy with this, but fixing it
really needs a functional pythonw in non-framework builds, and I don't
think I can do that before 2.3a1 (but I'll try:-).
env.
This adds @CFLAGS@ and @CPPFLAGS@ to the end of the respective
variable definitions. It also adds $(LDFLAGS) to the $(CC) invocation
to build $(PGEN).
Immediate benefit: when you use "make -t" to avoid a global recompile
after a trivial header file touchup, Make will no longer create files
named all, oldsharedmods, and sharedmods.
(Not sure if I tracked down all such targets. Not sure if I care.)
the framework, the MacOSX apps and the unix tools.
Most of the hard work is done by Mac/OSX/Makefile.
Also, it should now be possible to install in a different directory,
such as /tmp/dist/Library/Frameworks, for building binary installers.
The fink crowd wanted this.
if we are running in an OSX framework enabled build directory, test that
the framework infrastructure exists. This catches the very common
error of doing "make install" in stead of "make frameworkinstall".
us to completely decouple the framework from the executable, so we
can use a two-level namespace.
- Do framework builds with a twolevel namespace.
- Reorganized the code that creates the minimal framework in the build
directory, to make it more robust against incomplete frameworks (from
earlier aborted builds, or builds of previous Python versions).
This patch fixes make install for Cygwin. Specifically,
it reverts to the previous behavior:
o install libpython$(VERSION)$(SO) in $(BINDIR)
o install $(LDLIBRARY) in $(LIBPL)
It also begins to remove Cygwin's dependency on
$(DLLLIBRARY) which I hope to take advantage of
when I attempt to make Cygwin as similar as possible
to the other Unix platforms (in other patches).
I tested this patch under Red Hat Linux 7.1 without
any ill effects.
BTW, I'm not the happiest using the following
test for Cygwin:
test "$(SO)" = .dll
I'm willing to update the patch to use:
case "$(MACHDEP)" in cygwin*
instead, but IMO that will look uglier.
OSX framework build process. Things fixed/modified:
- the filesystem case-sensitivity test now works for builds outside
the source directory
- various other fixes for building outside the source directory
- python.app now has a target in the main Makefile
- WASTE and AquaTk are found more automatically
This patch removes a vestige part of the Cygwin make rules
that didn't quite make it over during the flattening of the
Makefiles. In its current form, it creates a def file but
incorrectly calls it libpython$(VERSION).dll.a which
immediately gets overwritten by the next command.
Obviously, this is useless. It appears, it was useless
in the old nested Makefile structure too. :,)
PEP 285. Everything described in the PEP is here, and there is even
some documentation. I had to fix 12 unit tests; all but one of these
were printing Boolean outcomes that changed from 0/1 to False/True.
(The exception is test_unicode.py, which did a type(x) == type(y)
style comparison. I could've fixed that with a single line using
issubtype(x, type(y)), but instead chose to be explicit about those
places where a bool is expected.
Still to do: perhaps more documentation; change standard library
modules to return False/True from predicates.
Also move all _PyMalloc_XXX entry points into obmalloc.c.
The Windows build works fine.
The Unix build is changed here (Makefile.pre.in), but not tested.
No other platform's build process has been fiddled.
1. configure doesn't handle HP-UX release numbers
(e.g., B.11.00), resulting in MACHDEP = "hpuxB".
2. After checking for wchar.h, configure doesn't
include it when checking the size of wchar_t.
(Python 2.2b1 on HP-UX 11.00)
This is a big one, touching lots of files. Some of the platforms
aren't tested yet. Briefly, this changes the return value of the
os/posix functions stat(), fstat(), statvfs(), fstatvfs(), and the
time functions localtime(), gmtime(), and strptime() from tuples into
pseudo-sequences. When accessed as a sequence, they behave exactly as
before. But they also have attributes like st_mtime or tm_year. The
stat return value, moreover, has a few platform-specific attributes
that are not available through the sequence interface (because
everybody expects the sequence to have a fixed length, these couldn't
be added there). If your platform's struct stat doesn't define
st_blksize, st_blocks or st_rdev, they won't be accessible from Python
either.
(Still missing is a documentation update.)
it may depend on. It's really annoying that thread.o doesn't get
rebuilt when the .h file is changed! :-)
The dependency is on *all* the Python/thread_*.h files -- that should
be sufficient and rarely cause unneeded recompilations.
- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.
- Made framework builds work for MacOSX. The configure arg is now
"--enable-framework".
- Added an install target frameworkinstall which installs the framework.
- Ripped out Next/OpenStep support, which was broken anyway.
- Made the MacOSX toolbox glue dependant on a --enable-toolbox-glue
configure arg. This should make naked darwin build work again (untested).
A few targets have been added to Makefile.pre.in, and on inspection they
look harmless to non-MacOSX machines, but it is worth checking.
Closes bug #420601 and patch #450350.
Python warning which can be catched by means of the Python warning
framework.
It also adds two new APIs which hopefully make it easier for Python
to switch to buffer overflow safe [v]snprintf() APIs for error
reporting et al. The two new APIs are PyOS_snprintf() and
PyOS_vsnprintf() and work just like the standard ones in many
C libs. On platforms which have snprintf(), the native APIs are used,
on all other an emulation with snprintf() tries to do its best.
doesn't work -- it actually prevents the extensions from being built
properly. So I'm changing the "sharedmods" target to what I presume
it was before:
PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py build
Mac/macglue.c into the core interpreter. This file contains the glue code that
allows extension modules for Mac toolboxes to live in different shared libraries
but still communicate with each other. The glue code is controlled by the
USE_MAC_TOOLBOX_GLUE define.
new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER
new C API PyObject_GetIter(), calls tp_iter
new builtin iter(), with two forms: iter(obj), and iter(function, sentinel)
new internal object types iterobject and calliterobject
new exception StopIteration
new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py)
new magic number for .pyc files
new special method for instances: __iter__() returns an iterator
iteration over dictionaries: "for x in dict" iterates over the keys
iteration over files: "for x in file" iterates over lines
TODO:
documentation
test suite
decide whether to use a different way to spell iter(function, sentinal)
decide whether "for key in dict" is a good idea
use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?)
speed tuning (make next() a slot tp_next???)
The changes cause compilation failures in any file in the Python
installation lib directory to cause the install to fail. It looks
like compileall.py intended to behave this way, but a change to
py_compile.py and a separate bug defeated it.
Fixes SF bug #412436
This change affects the test suite, which contains several files that
contain intentional errors. The solution is to extend compileall.py
with the ability to skip compilation of selected files.
NB compileall.py is changed so that compile_dir() returns success only
if all recursive calls to compile_dir() also check success.