I’m a C++ programmer, and I’ve got a box that has some free space on its SSD. I might consider contributing programming time to the Synfig project.
A pre-requisite for that, of course, is setting up my box so that it is ready for developping/debugging Synfig. My Windows 10 box is currently set up for MS Visual Studio, so this will probably not do here, and I’ll have to install different things.
Actually, this is something that I already attempted about half a decade ago. I went by the documentation for “compiling Synfig” that was accompanying the project at that time. I was led astray and ended up attempting to build a configuration that only should have worked in principle, but had obviously never actually been done for a very long time: Instructions were badly outdated and broken, lots of components didn’t harmonize in myriads of little ways. I failed utterly in the end.
So this is something that I definitely want to avoid this time around.
What I’m after is a combination of
an IDE
a codetrain
a set-up
that I can reproduce on my Windows 10 box and that is actually used by people that actively program for the Synfig project.
I must be able to start up from Windows 10 at the click on an icon. (I want as little hassle as possible from preparations. If preparations entail starting up Linux in an emulation or something, that needs to happen fairly automatically)
The set-up must be able to compile and assemble a working version of Synfig that is identical or at least compatible to the version that Windows users install.
It should do good code analysis (“where is this variable used/defined”, “what file contains what classes and methods”, “what functions call this function”, etc.)
It should support refactoring (renaming variables, isolating chunks of code into methods, etc.).
Whenever the software crashes, it should end up in a comfortable debugger, preferably a visual one that lets me trace/modify executed code, stacks, and watched variables in panes.
I can live with having to enter all git commands manually into a console, but a nice integration of a visual git would definitely be a plus.
This is probably something that has already been written up somewhere, if only in order to onboard the people that join for projects such as Summer of Code. I’m happy to start reading if you point me to the actually correct and current documents.
In fact, we don’t compile from Windows.
We use cross-compilation and packaging from a Debian Docker image, with an (almost) dedicated build system, with MinGW and NSIS.
It’s easy.
You build your docker image (or download the default one).
When you start the building script, it downloads all the required libs (as source) and compile them (one time only, kept on your disk).
Then the git repository is downloaded and compiled automatically.
Some libs can be updated/refreshed if need.
At the end, you will have an NSIS installer and a zip (portable) for Windows, and AppImage for Linux, in 32 and 64bit flavours (you can select which OS/bitness you want from parameters)
The libs are selected in an interdependant way, and the internal configuration has to be carefully modified, but you can still develop with an IDE as indicated by Kai.
I’m not generally opposed to Linux. In fact, in yonder years long passed, I even started out with Linux on all my home boxes. That was at a time where you still had to re-compile the kernel first thing after installing it in order to get a non-Finnish keyboard layout , so, ages ago.
The hardware of my current box is perfect for my current needs IMHO; but the ageist discriminatory pig MS refuses to upgrade it to Windows 11: All the components would comply with all the pre-requisites that are actually needed (CPU command set, TPM, physical memory etc.) except that MS deems my CPU to be too old . I massively resent that, and so I’ve weaseled the box into a setup that will get Windows 10 updates for several years to come.
From a practical vantage point, I’m in another open source project that’s partially written in C#, and that part needs MSVS to be programmed and compiled. So I can’t ditch the MS world completely just yet.
AFAIK, there are several good options to co-run Windows and Linux on the same box. I’ll look into them.
I recall a time, several years ago, where Synfig was rock stable when run under Linux but suddenly crashed all the time when run in Windows. At some point, even the official Morevna ’walkcycle’ course crashed under Windows for such mundane things as pulling down a guideline. And emergency autosave after crash didn’t work for Windows, either.
AFAICR, it turned out that an underlying third-party toolbox was to blame that had recently been upgraded to a major version: Its new version had very bad Windows stability at first, and its crashes ‘short-circuited’ Synfig’s crash recovery mechanisms.
I see a possible general problem in that episode: When a Windows user reports a crash in Synfig and their version of the program has been cross-compiled from the Linux side – how do we get a debugger to halt at the point of their error or exception, or at least get at an inspectable dump and stack trace?
We have a lot of people using Windows and who are able to compile Synfig in their IDE.
I was doing it too, with Cygwin at that time (se the old Dev:IDE_Windows, look at history ).
The issues are mostly about spaces and foreign characters in filename and about libs versions used in the user’s system, which can vary.
There was an issue with GTK rendering, another about the version of FFMPEG with different options.
Generaly, if it works under Linux, it would under Windows (but third parties and Windows-specific)
The best possibilities are to use WSL2 or Docker/Podman to compile (what I’m doing now as I messed with some libs in my Ubuntu 22.04).
The most important is to make it standard and reproducible, to avoid “it works on my machine”.
Code analysis helps, but beware side-effects and regressions if you want to refactor.
Currently, there is a load of spaghetti that I would prefer to see on my plate.
And yes, a proper documentation is still lacking …
, so, ages ago.
. I massively resent that, and so I’ve weaseled the box into a setup that will get Windows 10 updates for several years to come.
).
