Get --with-next-framework to work again (on OSX at least)

[jackjansen]

BPO	450350
Nosy	@loewis, @jackjansen
Files	@diff2

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/jackjansen'
closed_at = <Date 2001-08-15.01:35:33.000>
created_at = <Date 2001-08-12.22:12:12.000>
labels = ['build']
title = 'Get --with-next-framework to work again (on OSX at least)'
updated_at = <Date 2001-08-15.01:35:33.000>
user = 'https://github.com/jackjansen'

bugs.python.org fields:

activity = <Date 2001-08-15.01:35:33.000>
actor = 'jackjansen'
assignee = 'jackjansen'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2001-08-12.22:12:12.000>
creator = 'jackjansen'
dependencies = []
files = ['3523']
hgrepos = []
issue_num = 450350
keywords = ['patch']
message_count = 7.0
messages = ['37293', '37294', '37295', '37296', '37297', '37298', '37299']
nosy_count = 2.0
nosy_names = ['loewis', 'jackjansen']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue450350'
versions = []

[jackjansen]

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.

[loewis]

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.

[jackjansen]

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.

[loewis]

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)?

[jackjansen]

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...

[loewis]

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.

[jackjansen]

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.