Kristjan,
I think everything was answered in my response to Anselm's reply.
There was one crucial point that I did not see by then:
My approach was hard to get done right, because of .DLL naming.
So I removed that idea and replaced it by a simple dynamic switch that
disables stackless features and enables a normal appearance as
"python 2.7.X (...)" if started by a "python.X" main program.
I also tossed the idea of switching things off by "STACKLESS_OFF".
It makes things more complicated.
Instead, I think to leave everything in and bump the version.
Stackless would IMHO either report itseld as
"stackless 2.8" with stackless extensions, or
"python 2.7.X" without stackless features but still compiles the same way,
for any X you see fit, and we just declare this as compatible enough,
because
extensions will have to be built, anyway.
I will re-write my proposal and try to implement the few changes,
although I'm pretty busy moving into another location this week.
Cheers - Chris
On 25.11.13 15:49, Kristján Valur Jónsson wrote:
Hello there.
I have only a few comments,:
-----Original Message-----
From: [email protected] [mailto:stackless-
[email protected]] On Behalf Of Christian Tismer
Sent: 24. nóvember 2013 02:49
To: [email protected]
Subject: [Stackless] Stackless 2.8 layout (or stackless python 404)
Points to be considered:
--------------------
It would make sense to go forward and name the executable file
"stackless.exe" or "stackless.so", accordingly.
It also makes sense to name the .DLL file on certain platforms
"stackless28.dll".
on unix, don't we already have python27.so? So I assume that
stackless28.so is what you mean.
Windows-Specifics
----------------
For the windows-builds, the situation is a bit complicated, since the windows
project files are not solely dependant from version.h, but still have explicit
dll
names in the property files.
I propose to duplicate those files and have versions for stackless and
cpython.
I also propose to report the version "python 2.7.6+" or something, if the
variable "STACKLESS_OFF" is set.
I wonder, do we need to have a STACKLESS_OFF version?
Were you thinking that the STACKLESS_OFF version would
be a "2.7" version with visual studio 2010?
Back-Ports:
----------
I propose to put all extensions that are not in "python 2.7.x" into #ifdef
STACKLESS statements. If "stackless 2.8" is compiled with STACKLESS_OFF, it
should create the expected python27.dll and not any code that has traces of
"python 2.8", also no extensions to it.
I think this will become a maintenance nightmare.
IMHO, if we need a pure 2.7, but only with 2010 features, then we should
just have that in a separate branch.
Once we start backporting selected 3.x goodies, keeping them
conditionally compilable is not going to be possible in the long term.
As a vague idea, I think it would be possible to create both "stackless 2.8"
and "python 2.7" using the same source. We could go ahead and create
them both,
together. The advantage of this would be:
Like I say above, I don't think this is a good idea. Already, just maintaining
the "#ifdef STACKLESS" part of regular stackless is tricky enough. I think
your proposal makes it even more tricky.
In short, there are two problems we are trying to solve:
a) create a completely python2.7 compatible library which supports VS2010
This has ABI compatibility issues but otherwise no objections from python-dev
b) create a stackless version with back ported features from 3.x. VS2010
support
is intrinsic to this. This is the feature we would call "Stackless 2.8",
again, without
any real objections from python-dev.
What I'm saying is that these two problems are sufficiently different that I
don't
think there is any reason to try to achieve them both with complicated
build-time mechanisms in the same source tree. Let's just use mercurial fine
branching mechanism to achieve the same result instead :)
Cheers,
K
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
--
Christian Tismer :^) <mailto:[email protected]>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
