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: ```python assignee = 'https://github.com/jackjansen' closed_at = created_at = labels = ['build'] title = 'Get --with-next-framework to work again (on OSX at least)' updated_at = user = 'https://github.com/jackjansen' ``` bugs.python.org fields: ```python activity = actor = 'jackjansen' assignee = 'jackjansen' closed = True closed_date = None closer = None components = ['Build'] creation = 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.

[61337411-43fc-4a9c-b8d5-4060aede66d0]

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.

[61337411-43fc-4a9c-b8d5-4060aede66d0]

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

[61337411-43fc-4a9c-b8d5-4060aede66d0]

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.