On 27.09.2017 11:37, Nick Coghlan wrote:
> On 27 September 2017 at 12:30, xoviat wrote:
>>> In short, I think your proposal is a good one, but how can we allocate
>>> manpower?
>>
>> (issue31595 on bugs.python.org)
>>
>> So what do others think of this? My sense of things is
> So how do we get there? I would think a fork and merge of both
setuptools and distutils would make sense. Preserve the building part
of the API, so folks could simply replace the import line an their
setup.py files to use the new tool.
There's no need to even replace the line in setup.py.
distutils works fine for its original purpose (building components for
the system Python in Linux distros),
What does Linux have to with it? In the eagle days, I found it most
helpful for Windows, actually. And it's very helpful for OS-X as well.
It was also great for pure python
I meant to include a link, sorry.
https://github.com/pfmoore/pylaunch/blob/master/build_zastub.py
On 28 September 2017 at 16:11, Paul Moore wrote:
> I use distutils to build a C program that embeds Python, for making
> standalone launchers. I'm not at all clear how I'd get
I use distutils to build a C program that embeds Python, for making
standalone launchers. I'm not at all clear how I'd get all the
information I needed to build a compatible Python (including the "find
the appropriate C compiler" dance) manually - I'd probably end up with
something that didn't
Enscons uses parts of distutils to get compiler flags and so on but does
not use Extension() to do the actual compiling. There might be a cleaner
way to do it that I was not able to find. There could be a cleaner
separation between parts of distutils related to how Python itself was
compiled and