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
