> I'm unsure, I've never fully understood the intention behind --with and > --enable. For instance, why is it "--enable-unicode" and "--with-threads"? I think the eventual choice is yours, given Guido's objections to gettext manual; my objections where primarily backed by this manual. > The alternative is of course that we also provide a > "--with-previous-framework". Any suggestions as to what it should do? :-) Based on your current patch, I think it is save to remove any claim that this does something useful on the Next. It may do, but that would be purely coincidental. > On a high level it is a very nifty way to package a shared library > complete with all its supporting files. These supporting files range > from things used at runtime (like the python Lib directory) to the C > header files needed when you want to link against the library to the > documentation. Ok. Then my question is: Why is it desirable to build libpython as a framework? You give some rationale below, but I fail to see the point. I'll pick what I think are your arguments to build a Python framework, and try to see what it gives to the end user - compared to the option of linking libpython into the Python interpreter. > Everything is in a single directory, so install/uninstall is a > breeze with no danger of missing things. In case of Python, "everything" is the header files, and the .py library, right? Couldn't you also get this by making Python an Application Bundle (which you intend to do anyway)? > Also, the structure of a framework allows you to have older, > incompatible versions of the library (and support documents) in the > framework as well, with these older versions only used by programs > that were linked against the framework when that version was > current. Again, why is that desirable? If you have multiple versions of Python installed, if each version has libpython linked statically, and comes with its own set of header files and .py files: there wouldn't be any older, incompatible versions of the library that you may need to defend against. > The framework patch in sourceforge is the first step. The next step > is to create a Python application bundle. We can then use a single > trick in the Python main() program, where it will check to see > whether it's being run from an application bundle and, if so, > whether there's a magic file in the bundle (__main__.py comes to > mind). If there is Python will run that file as the script. This > will give Python users "freeze" functionality without using a > compiler. For that second step, do you really need the first one? I agree that 'freezing' Python applications by just putting a Python installation into a subdirectory is cool (if I understand right how such a frozen application would work), however, I fail to see the role of the framework in here. You may wonder why I question that feature so much. To me, it is similar to building a shared libpython.so on Unix. I think this will cause many problems, and in no way it should be done just for a single platform (there were patches to do this for Linux, I believe, and such a patch to make it work specifically on UnixWare only even made it into 2.1). I think it is desirable that the feature "shared libpython" is implemented as uniformly as possible across systems. If Mac OS X wants to do it differently from everybody else, you need a very good reason. The only platform that already has a shared pythonXY.dll has a good reason: you cannot export symbols from the application to extension modules on Windows. Yet, this is also the only platform where the API version magic is meaningless, since extension modules break with every new Python version exactly because libpython is shared. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4