[Stackless] Stackless 2.8 layout (or stackless python 404)

[Kristján Valur Jónsson]

Hello there.
I have only a few comments,:

> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Christian Tismer
> Sent: 24. nóvember 2013 02:49
> To: stackless at stackless.com
> 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