These patches to Makefile.pre.in, configure.in and Modules/getpath.c make --with-next-framework work again, for build as well as install. At least 50% of the credits go to Tony Lownds (as they say: the bits that show a strike of genius are his, the stupidities are mine:-)

--with-next-framework now has an optional argument saying where to install the framework (default /Library/Frameworks). Using --with-next-framework will also automatically set $prefix correctly.

Makefile.pre.in will create a temporary skeleton framework in the build directory against which python.exe is linked and which is used when python is run from the build directory (for building the extensions, for instance). "make frameworkinstall" will install the complete framework (including Lib/python2.2 and all that jazz) in the final location.

getpath.c now expects a "normal" python installation even in a framework, and it has also acquired (framework only) a bit of magic to detect that it is running with the skeleton framework from the build directory.

The main reason for posting the patch here is that there's quite a bit of changes, and I can never be sure that it doesn't break things on other platforms.

Assigned to Martin because he's one of the config purists and has provided valuable feedback before.

Logged In: YES 
user_id=21627

Please see 
http://mail.python.org/pipermail/python-dev/2001-August/016944.html
for my primary concerns about this change in configuration 
procedures.

As for the specific patch:
- There is a comment "NeXT framework builds require that 
the 'ar' library", however the next fragment does not 
mention either are nor libtool. The comment, at a minimum, 
should explain what BLDLIBRARY is.
- What is the rationale for the various -u options? I find 
it extremely strange that you need such options. What 
happens if you leave them out? Where does the specific 
selection of -u option come from? Is that a hack around a 
problem that is not fully understood, or is it a procedure 
endorsed and documented by Apple? This is mysterious 
enough to require an elaborate comment on what exactly 
these symbols are, and why it is necessary to make them 
undefined.

Logged In: YES 
user_id=45365

Ok, attached is a new patch which should address the issues you've raised:
- --enable-framework in stead of --with-next-framework
- comments updated

Also a few minor things were changed to make building the
plat-darwin1 directory work, and getting better linker
errors when building extensions.

Logged In: YES 
user_id=21627

The patch looks technically fine now, also I still cannot 
see the utility of building libpython as a framework (and 
you add some quite code just for that feature).

Also, you might recheck the likelyhood that 
--enable-framework really works on OpenStep and Rhapsody 
still. Likewise, would it work on a naked Darwin system 
(IOW, does Darwin proper include the Foundation, Carbon, 
and System frameworks)?

Logged In: YES 
user_id=45365

As to the utility of frameworks: did you see my pythondev-post? Not convinced??!?

As to OpenStep, Rhapsody and naked Darwin: I have absolutely no way of checking that.
If someone responds to my "anyone using NeXTStep" question I'll ask them to try it.

But, all that aside: did you check that these mods don't break builds on your system?
That was my main reason for posting it here: from inspection it shouldn't break anything
but I haven't tested it...

Logged In: YES 
user_id=21627

Please see
http://mail.python.org/pipermail/python-dev/2001-August/016990.html
for further comments.
If you are uncertain whether it works on any NeXT flavour, 
I recommend you remove the claim that it does. As for 
Darwin proper, doesn't your pulling in of the "Mac toolbox 
glue" pretty much destroy any hope that the framework code 
work on Darwin alone?

The code itself works fine on Linux, no worries here.

Logged In: YES 
user_id=45365

Checked in the changes, with most of Martin's suggestions
incorporated (including "rip out next support", not including "why are you doing this in the first place":-).

These versions of Makefile.pre.in and configure.in should definitely be tested for ill effects on other unix platforms.