Is there interest from the solvespace team in an AppImage?

@probonopd, we all interested ;-)

Can you make at least one AppImage of SolveSpace v.2.1 for 32bit for test it?

Can you provide either debs compiled on debian oldstable, Ubuntu 12.04 or older; or rpms compiled on CentOS 6? Then I could easily take it from there.

@probonopd Not really. The current automated build infrastructure we use (Travis for *nix) only has 64-bit Ubuntu trusty, which is one of the reasons we have the problem.

Here is an AppImage I generated from your provided Ubuntu trusty deb files:
https://bintray.com/probono/AppImages/SolveSpace#files

And here is the recipe:
https://github.com/probonopd/AppImages/blob/master/recipes/solvespace/Recipe
Note that this merely repackages the existing binaries, so that they not only run on Ubuntu but also other distributions. But this also means that it will run on systems that are no older than Ubuntu 14.04, so most distributions from 2015 and later should be able to run it.

To make it run on older distributions, we would need to compile on an older build system; and to produce 32-bit AppImages, we would need to compile for 32-bit. Both is significantly more work.

You could also incorporate the AppImage generation into your travis builds.

To make it run on older distributions, we would need to compile on an older build system; and to produce 32-bit AppImages, we would need to compile for 32-bit. Both is significantly more work.

Yeah. Which is exactly why it's still not done... It is actually not enough to build on an older system while distributing .debs, the debs I currently build don't install on Xenial.

You could also incorporate the AppImage generation into your travis builds.

Possible, but probably doesn't make a lot of sense until I can generate 32-bit debs, which is as hard as any other part of this list, really.

Actually the latter is not so hard, as shown here:
travis-ci/travis-ci#5770

This allows you to run 32-bit trusty inside Docker on Travis CI.

@probonopd, here is some unofficial SolveSpace 2.1 for 32bit (i386)

• deb installer - https://www.cnc-club.ru/forum/download/file.php?id=82708
• binary - https://www.cnc-club.ru/forum/download/file.php?id=82688

So, try make AppImage for 32bit using them (for testing)

It was founded here

• http://www.cnc-club.ru/forum/viewtopic.php?f=154&p=283428

https://bintray.com/package/files/probono/AppImages/SolveSpace

So, I have looked at this again. Here are my thoughts:

• AppImage is in essence "just another distribution" we have to build for. It has less ABI problems due to the way it packages libraries, but it still has ABI problems, e.g. in glibc, in GTK plugin loading, maybe somewhere else.
• We do not have the resources to set up a Linux build farm. There are way too many combinations of (distro × version × architecture) in use. It is clearly not enough to provide just one or two of them, since we did that and people complained. With the proliferation of RPis and so on people will also complain there's no ARM version... etc.
• Building on Travis is not enough. Travis only has 14.04 which according to @probonopd is too new (!). I am definitely not bothering with oldstable, or really anything without GCC 5+, since we don't support that. I also dislike the idea of using Docker, since our Travis is already plenty fragile, and so I would like to not add another component to slow it down and create breakage.
• The .debs we used to build were useless if you didn't run 14.04 exactly. Both older and newer distributions couldn't use them well.
• The distributions are picking up. Debian Stretch and Ubuntu Yakkety will have version 2.2; I think it's also at least in AUR, AltLinux.

And here's the conclusion: the SolveSpace project should not provide any Linux packages at all, AppImage or not. It is the job of distributions to properly package software for all releases and architectures they have, and I will leave it to them.

If you want the freshest code, it is also not at all hard to build from source. You could even just run ./.travis/install-debian.sh && ./.travis/build-debian.sh on any Debian system, and that will make a working build for you. It has to, because our CI system depends on it.

@whitequark I respect your decision, but of course you can build AppImages on Travis CI with 14.04 - as long as you don't expect them to run on target systems older than 2014ish. I have good experiences with using 14.04-built binaries on newer systems.

That unfortunately still leaves out 32-bit binaries. I feel like a person external to SolveSpace but interested and familiar with packaging could produce much higher quality packages, such as AppImages, at much lower cost (since that wouldn't have to happen for every build, but only for releases, presumably, and wouldn't have to be maintained as much too).

Overall, probably the single most important part is that I already spend easily half of my time working on platform support. Adding Linux packaging there would just be too much.

So Linux stays a 2nd-class citizen compared to Windows and macOS, dependent on 3rd parties who may or may not fully understand your software :-/

Actually, so far the reverse has happened. The Debian Science packaging team made such a better job than me at it, that I have removed the in-tree debian/ stuff entirely in favor of using their repository.

So Linux stays a 2nd-class citizen compared to Windows and macOS, dependent on 3rd parties who may or may not fully understand your software :-/

There is no more to say...

@probonopd, think, if SolveSpace will ignore Linux we came to time, when it would be forked in independent project (like LibreCAD was forked from QCAD CE, when original author of QCAD try ignore Linux users).

And I won't this future for SolveSpace.

@whitequark, @jwesthues, @Evil-Spirit, PLEASE, think twice before drop Linux support!

@Symbian9 What? I didn't drop Linux support. I simply chose the same distribution model as the majority of software packages ever written for Linux or Unix.

I simply chose the same distribution model as the majority of software packages ever written for Linux or Unix

@whitequark, Ubuntu has standart way for distributing using Launchpad, but you already drop SolveSpace repo on Launchpad...

• https://launchpad.net/~whitequark/+archive/ubuntu/solvespace/+packages
• http://solvespace.com/forum.pl?action=viewthread&parent=574

#3 (comment)

CI builds with gcc-4.6 succeed. What gcc version and what compilation problem do you have?

https://github.com/solvespace/solvespace/blob/master/CMakeLists.txt

GCC 4.8/4.9 ship with broken but present . meh.

@whitequark, @Evil-Spirit, is it a way keep support for GCC 4.8.2 and Trusty (14.04)?

Or how run GCC 5.0 on Trusty if its not officially support?

• https://gist.github.com/beci/2a2091f282042ed20cda
• https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+packages

@Symbian9 GCC 5+ is a hard requriement. You can install gcc-5 from the ubuntu-toolchain-r repository that you have found, which is what I use for CI.

@whitequark, where are Linux binary for SolveSpace 2.2? And where gone deb's from 2.1 release page?

@Symbian9 Provided by your distribution (the 2.2 binaries will be built for Debian and Ubuntu in a matter of days). You can also build them yourself.

I have removed the 2.1 debs from the download page because 2.1 is already included in Debian and Ubuntu, and the packages in these distributions are better.

I have removed the 2.1 debs from the download page because 2.1 is already included in Debian and Ubuntu, and the packages in these distributions are better.

But Ubuntu have not binary for 14.04 LTS and 16.04 LTS, that was presented on SolveSpace release page on Github.

• http://packages.ubuntu.com/search?keywords=solvespace

@whitequark, So, please, recover at least those 2.1 binary for 14.04.

P.S.:

You can also build them yourself.

I cant, because I'm a user of 14.04 LTS and I'm NOT a programmer (already told you this info few days ago).

Dirty build for Trusty 14.04
https://launchpad.net/~alex-p/+archive/ubuntu/solvespace-trusty2

Thanks @Symbian9. Here is an AppImage I generated from your ppa:
https://bintray.com/probono/AppImages/SolveSpace#files

Code:
https://github.com/probonopd/AppImages/blob/master/recipes/meta/SolveSpace.yml

THANK YOU, @probonopd ! Can you create it also for 32bit?

Honestly, it's not my own repo. I contacted with alex-p and he made this .deb, so thanks must transfer to him.

The equivalent for this would be, say, a CentOS 6 chroot, correct?

There's no equivalent. GTK 3 does not have ABI stability guarantees; you cannot target "GTK 3". You can target "GTK 3.20", "GTK 3.22", etc. If I built SolveSpace against libgtk 3.2 then those binaries would have long stopped working on modern Debian.

Using gtkmm makes this an order of magnitude more complicated because libstdc++'s ABI depends on the set of flags used to build it.

If you choose to bundle your private glibc, then you need to bundle all of the glibc package including the matching NSS plugins. But again, I think the better way is to compile against an "old enough" glibc and not bundle it privately.

That's not how it works. The point of having loadable NSS plugins is so that 3rd party software (e.g. samba) can provide their own NSS plugins, and so provide new resolvers, etc. The same way with theme engines.

Perhaps removing the dependency on native-widgets entirely would be a good thing? SDL is a pretty reasonable cross-platform target, and it certainly looks like that would simplify a lot of your build stuff. Especially as the project moves on to android and emscripten.

It seems like a pretty complicated artiface to support "text editors, menu bars, tooltips and file pickers".

This implements native file-dialogs with "No third party dependencies for building or linking" for use under SDL. It only support desktop-os's though.

For reasons outlined many times before, no. Also, that still depends on GTK 3 on Linux, so it doesn't even solve the problem.

There's no equivalent. GTK 3 does not have ABI stability guarantees; you cannot target "GTK 3". You can target "GTK 3.20", "GTK 3.22", etc.

That is because GTK+ 3 still in development, and as such, apparently still a "moving target". If you target GTK+ 2 which is stable by now then you should not have these hassles. (In my personal view, GTK+ 3 should have been named 2.99.x until the ABI was stable, which was apparently GTK+ 3.22, released 21 September 2016 https://www.reddit.com/r/linux/comments/6ad7v0/is_gtk3_stable_now/).

I implicitly expect any application written against GTK+ 3.22 to work on all future GTK+ 3.xx versions. If that is not the case, I will consider it as a bug.

We should expect from a project like GTK+ to release stable versions at some point, with a major version number if they follow semver, and then keep that ABI working throughout the major version.

For reasons outlined many times before

Well, it's up to you to prioritize things how you're going to. It's a subjective judgment, and you're closer to the project and better able to make these calls. I think you'll more and more see that way of handling things preventing developers from "scratching their own itch", so to speak. Single-developer projects are easier to manage, but they don't scale. It looks like you've got a bunch of people at least interested, and a few open pull-requests. Hopefully you can leverage that into something that does scale.

Anyway, that's the last I'll bother you about this for a bit ;p

Single-developer projects are easier to manage, but they don't scale. It looks like you've got a bunch of people at least interested, and a few open pull-requests. Hopefully you can leverage that into something that does scale.

The main thing that used to prevent merging those was the CLA. Once I work out a few final approvals it will no longer present any problem.

The main issue that people contributing code encountering is the somewhat esoteric kind of C++ that SolveSpace is written in. I've been refactoring that over the year or so without (hopefully) losing of its straightforwardness, so that should also be less of an issue.

I really don't think migrating to a slightly different immediate mode UI toolkit makes much difference.

The main issue that people contributing code encountering is the somewhat esoteric kind of C++ that SolveSpace is written in.

Most of the features I expect people will want to implement aren't kernal features. As long as the solvespace solver has a stable API, it shouldn't matter if it's written in esoteric cpp or as assembly running on a custom-written VM.

Almost every feature that people want implemented relies on two things

• Custom UI elements.
• Modifying data that solvespace uses to solve stuff.

Openscad, the current most popular CAD tool, doesn't even maintain it's own cad kernal. It's just a UI wrapped around CGAL (which is one consumer for the CSG trees it produces).

The top-priority for enabling third-party contributors is, in my opinion, making it easy for developers to do those two things. You're already on the way to doing well with the later in #75. You don't need a stable interface to the kernal, you need a stable interface to the datastructure the kernel consumes.

Once those entry-points are sufficiently well-defined, you could write new features in python (actually, a pretty good choice for things like importing SVGs) or javascript or whatever.

More importantly, the code quality/style of features doesn't matter too much, since they're interacting with the kernal and UI through a less-powerful api. If something turns out crappy, it's not laced throughout the whole codebase.

So that's my pitch. Make the entry-points for (most) third-party code as simple as humanly possible in order to minimize contributor friction. Many new features are just a UI and a transform function acting on the data structure.

But I really don't want to derail the discussion. Just things like "The main issue that people contributing code encountering is the somewhat esoteric kind of C++ that SolveSpace is written in" compel me to explain myself.

I really don't think migrating to a slightly different immediate mode UI toolkit makes much difference.

If this will look like the same code over all platforms, it will be better. Every time I looking at SolveSpaces code, I wanted to rewrite it using QT. The only thing that stops me is what it needed to deal with CMake and QMake in some especial way. I like to write any code, dead-hard features, math, anything, but HATE this kind of wired ugly languages (batch, bash, CMake, QMake etc.) Why don't do it e.g. in C++, lua, python, any NORMAL LANGUAGE. Why are they invented new languages, and why it is so ugly?

You don't need a stable interface to the kernal, you need a stable interface to the datastructure the kernel consumes.
Once those entry-points are sufficiently well-defined, you could write new features in python (actually, a pretty good choice for things like importing SVGs) or javascript or whatever.

You're missing an important part: SolveSpace not only has a data format, but it also requires hundreds of invariants in its data to be held. It's not enough to just say "here's how requests are stored", by far; you'll just get people tripping on asserts deep within SolveSpace, with no easy way to debug.

This is the same reason SolveSpace doesn't export a Python/Lua/etc interface via SWIG right now, by the way.

More importantly, the code quality/style of features doesn't matter too much, since they're interacting with the kernal and UI through a less-powerful api.

That's how you get quality software like FreeCAD.</sarcasm>

I like to write any code, dead-hard features, math, anything, but HATE this kind of wired ugly languages (batch, bash, CMake, QMake etc.)

Sure, don't do any of that then. I have always handled this kind of issues for any contributions, didn't I? CMake sucks. The reason we're using CMake is it's still better than most of the alternatives for what we're doing.

Every time I looking at SolveSpaces code, I wanted to rewrite it using QT.

Look at the "platform" branch in this repo. 95% of the benefit of using Qt with less than 1% of code, bugs, compilation time, etc. It's not like we can use Qt if compiling with Emscripten, so Qt will not solve every problem anyway.

it also requires hundreds of invariants in its data to be held.

Would you mind elaborating on that?

Would you mind elaborating on that?

Right now SolveSpace assumes that the only data it will encounter is the data that can be created via its UI. If it's anything else, it will assert or even segfault. For example, if you create a point-point coincident constraint between a point and a line? That's an assert and a crash, and you don't even get a nice error message. The only code that prevents this from happening through the GUI is the GUI code that validates the input.

Look at the "platform" branch in this repo.

That's good.

The only code that prevents this from happening through the GUI is the GUI code that validates the input.

Yes, data should be separated from algorithms and UI. MVC, call it what you will.

I would advocate for using the same data structure for the save file and the internal data structure, once they are separated. If that's not already the plan.

I would advocate for using the same data structure for the save file and the internal data structure, once they are separated.

This is not viable in the long run because the save files must have perfect forward compatibility (and gracefully degrading backwards compatibility). But of course there's no reason for them to intentionally diverge.

I don't know how protocol buffers handle it, but capnproto has pretty good support for evolving your protocol. I would advocate that for changes outside of that, a version bump and conversion process be required. I presume protocol buffers has a similar system in place?

I'm going to use flatbuffers, and sure, it has a similar mechanism. I am against any such conversion process, the migration to flatbuffers should be the last breaking change to the file format. If needed, just write the data twice, in the old and the new formats.

@probonopd, could you try build AppImage of 2.3 release using next DEB (it liitle uncomplite, but work under PuppyLinux Xenial64)

• solvespace_20162312-2.3_amd64.deb - http://solvespace.com/forum.pl?action=attachment&id=2119

Details (by Larry Hammer)

• http://solvespace.com/forum?action=viewthread&parent=1419&tt=1505280021

Which concrete problem are you running into?

@probonopd, this DEB not include dependency info (manualy I istalled libspnav0 and libglew-1.13 to get work this DEB on PuppyLinux Xenial64, but not yet test it on real xUbuntu 16.04)

Then the deb has a bug that should be fixed.

In the meantime, you can add a section to your .yml file like this:

ingredients:
  packages:
    - solvespace
    - libspnav0
    - libglew-1.13

Once the deb is fixed, you can delete the packages: section.

@probonopd, since it require libglew-1.13 for Trusty 14.04, then need add next PPA with backported libglew1.13

• https://launchpad.net/~anton+/+archive/ubuntu/photo-video-apps/+sourcepub/6101687/+listing-archive-extra

    ppas:
        - alex-p/solvespace-trusty2
        - anton+/photo-video-apps

So, who in this project is interested in maintaining an official AppImage? I am happy to help that person but since AppImage is a tool for upstream packaging (by the original authors of applications), I won't be that person. Any volunteers to take over maintainership?

I've already mentioned the reasons for not building AppImages. They have not changed.

Then we quit this here and I am sorry having wasted your and my time. @Symbian9 kept contacting me about helping with the SolveSpace AppImage and I have invested a lot of time so far.

@phkahler @Evil-Spirit

Might be worth revisiting this issue? Appimage would be a very nice way to deploy this, and it looks like a lot of work has already been done.

@traverseda As a Linux user myself, this may seem odd but I'm not too concerned about Linux users. There are Debian packages for 2.3, Fedora has 2.3 in a COPR repo and there are now Snap packages - whatever that is I think it's great the @ppd has been taking care of it. The more ways people can get it the better! It's building for windows and getting it right for OSX that I'm most concerned about, though there are people around here who can probably get that done when 3.0 is ready. Which BTW can be any time as far as I'm concerned ;-)