Issue403678
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-02-08 06:39 by donnc, last changed 2022-04-10 16:03 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
None | donnc, 2001-02-08 06:39 | None |
Messages (13) | |||
---|---|---|---|
msg35627 - (view) | Author: Donn Cave (donnc) | Date: 2001-02-08 06:39 | |
(Obsoletes part of #103487) Use the "configure" procedure for platform specific values in setup.py. Build setup.py from setup.py.in - setup.cfg.in was a nuisance anyway. The particular configure options for setup.py in this patch are for BeOS, but it would be worth a look to see if some or all of the USE_xxx options there should get in there, especially if controlled by --with-xxx flags. |
|||
msg35628 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2001-02-08 16:38 | |
Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. |
|||
msg35629 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2001-02-23 16:37 | |
Donn, is this patch still relevant? Do there remain BeOS-specific issues to fix? Probably separate patches and bugs should be opened to handle any outstanding problems. |
|||
msg35630 - (view) | Author: Neil Schemenauer (nascheme) * | Date: 2001-02-08 18:45 | |
One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). |
|||
msg35631 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-02-08 13:01 | |
Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). |
|||
msg35632 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-02-08 18:29 | |
I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. |
|||
msg35633 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2001-02-08 22:51 | |
Na, it's not higher, only in this case, the design is going in the wrong direction. The new setup.py mechanism was meant to allow as much automatic configuration as possible (previously people had to edit Modules/Setup which was not difficult, but obscure enough to keep people from enabling important add-ons such as Tkinter). Now with the setup.py auto-detection mechanisms in place, there should be much less user interaction required to get a fully functional system. As for the other patches: many of the Python core team are currently out of town so there's a natural delay there. Nothing to worry about though. |
|||
msg35634 - (view) | Author: Donn Cave (donnc) | Date: 2001-02-08 18:12 | |
That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? |
|||
msg35635 - (view) | Author: Donn Cave (donnc) | Date: 2001-02-08 19:16 | |
I would be happy with extra symbols in Makefile, for setup.py to use. I think this system will be somewhat obscure for someone trying to figure out how to make a build work, so some pointer comments at the top of setup.py would be good. The last point there is not so clear to me -- it sounds like there's an intent to move a lot of logic from "configure" to setup.py. I look forward to seeing whether that does give us much more power and flexibility. It will put some pressure on the Python code base, though - I already have changes in for distutils and even os.py, to get through the build, not to mention the two unsuccessful attempts to get changes into setup.py. In 2.0, I came along pretty late in the beta with changes that make it build for BeOS. Here I am right at the beginning of 2.1 alpha, but the hurdle seems a lot higher. |
|||
msg35636 - (view) | Author: Donn Cave (donnc) | Date: 2001-02-08 23:43 | |
Not worried, just was trying to point out the good side of a throw-away system for the dirty business of platform warts. Anyway, with all that stuff to get done in setup.py, obviously the release is a ways off yet. |
|||
msg35637 - (view) | Author: Donn Cave (donnc) | Date: 2001-02-23 18:22 | |
Yes, it's still waiting to be resolved. The patch at least illustrates the problems (and of course it would also solve them if applied.) I have been hoping that you would put some thought into it, since your sense of direction on it is at least clear enough to know that it's different from where I would go. Since there's plenty of specific information about what needs to be done, I would prefer that you do at least something for it, in setup.py. Then after you have wrestled with the issues, I can check it out and see what you came up with, and if necessary straighten out anything that doesn't actually work. If you want, I might be able to take a look at what it would take to remove every single directory path literal ('/usr/X11R5', '/usr/lib/termcap', etc.), every platform literal ('aix', 'sunos5', etc.) and every reference to a platform specific flag ("linker_so + ' -shared' - what's up with that?) and put it in configure if it's really needed at all. Don't know if I could get that done for 2.1a3, but the sooner that gets cleaned up the better. |
|||
msg35638 - (view) | Author: The Written Word (Albert Chin) (tww-china) | Date: 2001-03-01 09:17 | |
Logged In: YES user_id=119770 I agree with donnc. We should definitely try and remove platform-specific items, hard-coded paths, etc. from setup.py. Let autoconf handle that. setup.py should be dumb and driven by autoconf. We just ran into a situation where we tried building 2.1CVS and wanted to feed -DUSE_SSL to Modules/socketmodule.c. We're on a Solaris machine which doesn't have libssl and libcrypto in the system linker search path. So, we have to add -I<path> and -L<path> options to the cc and ld line when Modules/socketmodule.c is built. How do we do this with setup.py? Dunno. We currently have a hack around this. I'd like a --with-ssl=<path> to configure this at ./configure time and have that get passed on to setup.py. Ditto for tk. And, hard-coding /usr/local/include and /usr/local/lib is just ugly. Also, termios does not build "out of the box" under Solaris. How do we disable this module? |
|||
msg35639 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2001-05-21 20:43 | |
Logged In: YES user_id=11375 Now irrelevant. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:03:43 | admin | set | github: 33878 |
2001-02-08 06:39:05 | donnc | create |