Should the C++ debugger be integrated into this library? about hxcpp HOT 7 CLOSED

Haxe and hxcpp have a special relationship in that they depend on each other. I consider it sufficient to have a version mapping between the two, as I suspect maintaining backward compatibility would be quite the ordeal.

from hxcpp.

To date, usually HXCPP has been designed where you can use the latest HXCPP with old versions of Haxe, but in order to use new versions of Haxe, you need the new HXCPP.

There's an exception to this with the debugger code, which requires "all_classes" in addition to "all_files", it can run with only a few changes:

jgranick/hxlibc@93b6d2c

I suppose this could be considered back-porting a new feature, though, but running the debugger can still be helpful for determining the cause of a crash

from hxcpp.

If that's just small changes that don't put a big mess in code, I guess we can have them added. Please send a pull request.

from hxcpp.

Is there a reason to name it HAXE_VERSION if our own define is haxe_ver?

from hxcpp.

Originally the decision to break backwards compatibility was made because
we though there was no one using the cold code, and version 3.1 would be
out soon. I hate breaking compatibility, so I would not have done it if I
though people were actually using it.

There are other issues with full paths and threads that need to be done
properly, so if you wait a few weeks for me to get around to it I can do it
properly and make it work for all versions of haxe. Of course, if haxe 3.1
is released, that would also solve the problem.

On Sat, Dec 21, 2013 at 8:02 AM, Joshua Granick [email protected]:

To date, usually HXCPP has been designed where you can use the latest
HXCPP with old versions of Haxe, but in order to use new versions of Haxe,
you need the new HXCPP.

There's an exception to this with the debugger code, which requires
"all_classes" in addition to "all_files", it can run with only a few
changes:

openfl@93b6d2chttps://github.com/openfl/hxlibc/commit/93b6d2cc6e452e7ad02bf9e6d4810f9634533b59

I suppose this could be considered back-porting a new feature, though, but
running the debugger can still be helpful for determining the cause of a
crash

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-31050869
.

from hxcpp.

Le 21/12/2013 12:03, Hugh Sanderson a écrit :

Originally the decision to break backwards compatibility was made because
we though there was no one using the cold code, and version 3.1 would be
out soon. I hate breaking compatibility, so I would not have done it if I
though people were actually using it.

There are other issues with full paths and threads that need to be done
properly, so if you wait a few weeks for me to get around to it I can do it
properly and make it work for all versions of haxe. Of course, if haxe 3.1
is released, that would also solve the problem.

In all cases, 3.1.0 will be an "unstable" release, so we cannot expect
to have all users switching to it until we reach 3.2.0 which will be the
next stable.

Funny I've actually just finish written a mail on [haxedev] regarding 3.1.x

Best,
Nicolas

from hxcpp.

I used HAXE_VERSION and HAXE to mirror some of the standard defines I found with other toolchains, for example, GNUC and GNUC_MINOR, etc. Surely this isn't the only way to do it, and I'm most interested in how Hugh would handle it (which always tends to be the best solution). I forget, but I don't think haxe_ver populated in a way it was useful to the C++ compile.

from hxcpp.