The reason I haven't made a release yet is that almost none of the major features that I planned for 3.0 are done. Unfortunately, my health has not permitted me to spend much time on SolveSpace in the last two years.

For now, there is nothing wrong with using the master branch. Regarding the CHAR_WIDTH issue, I could backport this to 2.x branch if this is really necessary.

Unfortunately, my health has not permitted me to spend much time on SolveSpace in the last two years.

I am sorry to hear that, and I wish you well.

there is nothing wrong with using the master branch

Most distros do not allow packaging from vcs trunk.

Regarding the CHAR_WIDTH issue, I could backport this to 2.x branch if this is really necessary.

It is not difficult to pull that patch in. I just imagine that there are other assorted fixes. In particular, the three latest commits here are useful.

No pressure either way, I wish you luck on your project!

Solvespace 2.3 is on VoidLinux now.
void-linux/void-packages#8037

Build scripts are here:
https://github.com/void-linux/void-packages/tree/master/srcpkgs/solvespace

I'll be happy to see the new version released.
I too wish well being for the developer and all people here.

Are there anyone experiencing a problem like this? #374

The reason I haven't made a release yet is that almost none of the major features that I planned for 3.0 are done.

We can call it 2.4 for now, not 3.0. I tried to compile on Mac os, but it requires full XCode installation for ibtool, and it looks I need to free up some space for it.

Unfortunately, my health has not permitted me to spend much time on SolveSpace in the last two years.

Wish you to get through all the issues well.

The latest binary release crashes on 10.12 and presumably newer releases as well, so the vast majority of OS X users cannot use it...and for some inexplicable reason older releases of Xcode that will install on older releases are gone, so I'm also unable to build it.

A build, even if it's tagged as alpha, would be greatly appreciated.

The latest binary release crashes on 10.12 and presumably newer releases as well, so the vast majority of OS X users cannot use it...and for some inexplicable reason older releases of Xcode that will install on older releases are gone, so I'm also unable to build it.

There will be no more SolveSpace on macOS in the future because macOS 10.14 completely eliminated the possibility of using OpenGL. (Officially it is only deprecated but de facto it is too broken for the application to render even a single frame.)

There will be no more SolveSpace on any version of macOS newer than 10.10 because that's the last version that successfully runs (very slowly) in a virtual machine. (In principle that guide lets you install 10.12, but I spent tens of hours trying to get it to work and never was able to.) Moreover that guide will not be updated again.

I do not currently have any Apple hardware, and the entirety of macOS code in SolveSpace was developed in a VM, which is no longer possible. In principle, if you donated me an Apple machine, I could fix the port. But seeing that this will work up until 10.14, I am not sure if it makes a lot of sense to do so.

It is an obvious fact that the desktop division of Apple does not care about independent developers of software portable between platforms. In light of that the macOS support should be considered deprecated, and I will likely remove it at some point as code I am unable to support in any way.

Also, to everyone else in this thread: I plan to cut release 3.0 once #389 is merged, since that is an extremely important feature.

Sad to hear that, even though it's not news that apple will use each opportunity to make life as hard as possible for people daring to think there is something other than apple. Thank you for your effort any way!

Btw, it seems that OpenGL is kind of obsolete on other platforms as well in favor of Vulkan, take a look at https://github.com/KhronosGroup/MoltenVK it claims to support mac.

Btw, it seems that OpenGL is kind of obsolete on other platforms as well in favor of Vulkan

This is sort of true, but I can't drop OpenGL because this would negatively impact a lot of people using SolveSpace on older machines, some of which are very popular--for example Thinkpad X220. Therefore I do not consider dropping OpenGL a viable option.

It is possible to support Vulkan through OpenGL, and in fact we already use a translation layer that does that, ANGLE. Unfortunately, ANGLE negatively impacts performance (see #278) so e.g. enabling it on Linux to get Vulkan support is probably a net negative.

Worse yet, ANGLE is somewhat of a nightmare to debug. Combining ANGLE and MoltenVK will make that significantly worse. It is theoretically possible to do so, but I don't expect to be able to actually get them to work together reliably. That being said, if an enthusiastic graphics programmer would do that, I would of course try to accomodate that effort, if at all possible to reasonably support.

A third option is to add a completely separate renderer that uses Vulkan next to our existing OpenGL 1 and OpenGL 3 / OpenGL ES 2 renderers. Unfortunately Vulkan is an extremely complex API that I have no experience using so I will probably not be able to do that.

This is similar to Metal with the added complication that I don't have any way to run macOS with Metal--macOS 10.11 that introduced Metal is not something I can run in a VM.

Also, to even start porting SolveSpace to use Vulkan it'd be necessary to get it to GTK 4 first, which is going to be an utter nightmare all by itself. I just looked at that and I don't know how long it'll be before that's feasible, probably years?

Also, to everyone else in this thread: I plan to cut release 3.0 once #389 is merged, since that is an extremely important feature.

Umm thanks for the vote of confidence. No pressure... But I agree it's important or I wouldn't be working on it. Hey, does this thing run native Wayland yet? ;-)

Btw, is there a chance that mac os build with settings as they were in 2.3 (working only on <10.12) will be released? :) This will indicate that mac os is supported in general but requires some rewrite for the broken APIs.

This will indicate that mac os is supported in general but requires some rewrite for the broken APIs.

macOS is not "supported in general" for reasons outlined earlier.

Hey, does this thing run native Wayland yet? ;-)

Closing as duplicate of #552. Please follow the discussion there.