Update haxelib with new version of hxcpp

[piotrzarzycki21]

Hi Folks,

I've asked same question on one of the channel on Discord, but didn't get proper answer. I see there is several several tags of hxcpp - releases happen already but non of them are uploaded to haxelib. Is this mean they are less important than uploaded 4.3.2? What has to be done in order to have available newest release in haxelib ?
It would be wonderful if someone could shed some more light on all of that. I'm quite new in Haxe world.

Thanks,
Piotr

[player-03]

Is there something blocking a Haxelib release? The community could help with whatever it is, in order to get this out sooner.

[piotrzarzycki21]

It looks like no volunteers to do that. We have started use tags in our project instead of waiting, but it would be awesome have this in haxelib.

[Aidan63]

@hughsando @Simn what needs to be done to get a new haxelib release out?

It's been about a year and a half since the last and with the end of the year (and therefor mbedtls 2.28 EOL) creeping up it would be good to get one more 4.3 release out to keep the openfl people happy before merging the mbedtls 3 PR.

@tobil4sk you've got a few open PRs, anything you'd want merged in before a new release?

I've gone through the commits since the last release and these seem to be the notable changes.

- Added support for killing processes on OS' other than Windows, Apple TV, and Apple Watch
- Added register capturing on Linux
- Added HXCPP_CPP17 define
- Added ASM and NASM support to build xml
- Added support for name and value entries to build xml
- Added tracy profiler
- Added support for Android NDKs higher than 21
- Added x86_64 support to older Android NDKs
- Added optional detaching of main thread

- Updated mbedtls to 2.28.2
- Updated sqlite to 3.40.1
- Updated zlib to 1.2.13

- Fixed SSL socket non blocking handshake throwing an exception on 64bit Windows
- Fixed Windows 64bit architecture detection
- Fixed critial error handler returning the wrong callstack
- Fixed ARM64 library names on Mac
- Fixed generational GC when used with HXCPP_ALIGN_ALLOC
- Fixed pthread structured being unaligned
- Fixed cppia crash on functions with empty bodies
- Fixed regression parsing integers which wrap around
- Fixed compilation with HXCPP_GC_DEBUG_LEVEL define
- Fixed compilation with MinGW
- Fixed enum parameters potentially returning null
- Fixed HXCPP_CLANG not being set when using clang
- Fixed pcre2 and mbedtls not being compiled with the c99 standard
- Fixed behaviour of indexOf and lastIndexOf on empty strings not aligning with other targets
- Fixed behaviour of directory reading function not aligning with other targets
- Fixed haxelib not being invoked with the current working directory

[tobil4sk]

We should probably release from a new branch without this commit: a08c621. It wouldn't make sense to remove something in a patch release, we should leave that until hxcpp 5.0.0. Should we also include all the feature additions?

In terms of my PRs, #1149 might be useful (but not necessary) for more convenient mac arm64 support for cppia. My other PRs aren't urgent for a release.

This minor patch might also be nice with the other MinGW fixes: #1152

[hughsando]

The only thing that might need updating are those release notes. Generally, there is a high level of backwards compatibility and the git version is almost always the best one to use. As for the pre-330 stuff, I'm not even sure the current version works with 3.3 (8 years ago) and I don't see a practical problem with removing it. I assume if someone is on an ancient haxe version, they are also on an old hxcpp version. I have not had much to do with hxcpp releasing for a while and I guess it could really use some more releases. My general feeling is that if someone is motivated to do a release, then it's probably a good thing. Those 2 PRs are probably worth including. Hugh

…

On Tue, 12 Nov 2024 at 17:49, tobil4sk ***@***.***> wrote: We should probably release from a new branch without this commit: a08c621 <a08c621>. It wouldn't make sense to remove something in a patch release, we should leave that until hxcpp 5.0.0. Should we also include all the feature additions? In terms of my PRs, #1149 <#1149> might be useful (but not necessary) for more convenient mac arm64 support for cppia. My other PRs aren't urgent for a release. This minor patch might also be nice with the other MinGW fixes: #1152 <#1152> — Reply to this email directly, view it on GitHub <#1058 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMWTVV7PZOQ47RZ3UR5AYT2AHFJJAVCNFSM6AAAAABRC7T6SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZQGA3DQNBRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Aidan63]

Keeping the haxe 3 removal sounds good to me, prevents all the hassle of branching and cherry picking features that way.

I've opened a merge to update the change log with what I added above, not sure how much detail you usually like but I can tweak it as required.

Once those two other PRs and the release notes is done is it just a case of someoone with the right permissions to upload the zip from the CI release to haxelib?

[tobil4sk]

As for the pre-330 stuff, I'm not even sure the current version works with
3.3 (8 years ago) and I don't see a practical problem with removing it.

I had a misconception that this would have broken Haxe 3.4 as well. I've just tested with that and it seems to work alright (perhaps it may even work with 3.3.1). As long as haxe 3.4 still works (at least until hxcpp 5), then I have no issue with support for older versions being removed.

This may still be a leftover artifact from old haxe 3 versions: #1148