Hello again! This new year's update announces some interesting new beginnings for the FreeCAD project, though it's a little short since I got some much needed vacation time over the last two months.
In November a strange bug was found in the OpenFOAM package which led to
only one core being used during builds, even though the logs reported an
N core build. In the worst case scenario, on the
this led to an increase in build times from 17 to 92 hours! I did some
troubleshooting on this but found it a bit difficult since OpenFOAM uses a
bespoke build system called
wmake. I found myself wishing for the simplicity
of CMake, and found there was an experimental repo implementing support for
it but it didn't seem to work
out of the box or with a bit of effort. I wonder if there's any consideration
amongst OpenFOAM developers in moving away from
Anyway, OpenFOAM ended up getting removed from Debian Testing, but thankfully
Adrian Bunk identified the problem, which is that the environment variable
MAKEFLAGS was getting set to
'w' for some reason, and thus falling
wmake code block that set up a proper parallel build for
OpenFOAM. So, unsatisfyingly, as a workaround I uploaded the latest OpenFOAM
version, 1906.191111, with
unexport MAKEFLAGS. It would be nice to find an
explanation, but I didn't spend much more time digging.
So, to end on the good news, the newest bugfix version of the OpenFOAM 1906 release, from November 11th 2019, is available for use going into 2020!
It was a bit last minute, but I finally decided to attend FOSDEM 2020. I had balked a bit at the cost since flights from the US are around $900, but decided it would be an important opportunity for FreeCAD developers and community to get together and possibly do some important work. Thankfully, Yorik and other senior FreeCAD developers thought it would be a good use of the project's Bountysource money to cover the cost of one ticket, split in half between myself and sliptonic, a developer from Missouri. He focuses on the Path workbench and FreeCAD in CAM applications, an area I'm interested in moving into as I now have such machining equipment available to me through my local ATX Hackerspace. The three of us will be giving a talk, "Open-source design ecosystems around FreeCAD", at 11:20 on Saturday, so please come by and say hi if you're able to!
I'll be staying for a few days before and after FOSDEM, including attending the MiniDebCamp at Hackerspace Bruxelles on Thursday & Friday, interested in anything Debian/FreeCAD related, so I look forward to getting a lot of work done indeed!
For the past several summers, FreeCAD has participated in the Google Summer of Code program under an umbrella organization led by Sean Morrison of BRL-CAD. BRL-CAD is a very interesting bit of software with a long history, in fact the oldest known public version-controlled codebase in the world still under development, dating back to 1983-12-16 00:10:31 UTC. It is inspired by the development ideas of the era, a sort of UNIX philosophy for CAD, made up of many small tools doing one thing well and meant to be used in a normal UNIXy way, being piped into one another and so forth, with a unifying GUI using those tools. Since it's made up of BSD/LGPL licensed code, it ought to be available as part of the Debian Science toolkit, where it may be useful for FreeCAD as an included alternative CAD kernel to the currently exclusive OpenCASCADE. For example, fillets in OpenCASCADE are somewhat buggy and unmaintainably implemented such that an upstream rewrite is the only hope for long-term improvement. BRL-CAD could potentially improve FreeCAD in areas like this.
It turns out a Debian Request for Packaging bug for BRL-CAD has been open since 2005. I plan to close it! It turns out there's already existing Debian packaging work, too, though it's quite a few years old and thus some adaptation still is required.
Recently, FreeCAD has been unbuildable in Debian Sid because of issues related to PySide 2 and the Python 3.8 migration. This is complicated by the fact that the upstream fix has been released but in version 5.14.0, which builds fine with Qt 5.14, although Sid currently has 5.12. Furthermore, the PySide 2 package itself isn't building at the moment either! Since FreeCAD depends on PySide 2 and Qt, and I use the Qt-based KDE as my desktop, it seems like taking on maintenance of PySide 2 is something I should do to get started in this realm. However, the Qt/KDE Team's packaging practices and tools are rather different than the ones I'm used to for Science Team packages. This makes sense: Science Team packages are very often a single Git repo, but Qt5 for example is really 44 Git submodules smushed together. As such, things are a bit different! Once I get things taken care of for the package, I will try to write up some notes to help others interested in getting started, especially since KDE packaging could use some help.
I'm very happy to announce that the FreeCAD project is now among the many open source software sponsorships by DigitalOcean.
One of the first things I did when interested in FreeCAD was to try to take on the responsibility of maintaining the project's infrastructure, since that would free up time for people to work on FreeCAD itself. FreeCAD's 17 years old now, and some of our infrastructure stack is about as dated. However, it isn't easy to just move things, I had to get things up to speed first and try to minimize disruption, so it's been a slow process. I'll go into more details in a technical blog post on the matter after I've finished our migration, hopefully by the end of this month, including details on our new setup, with the goal of allowing people to get set up with a dev environment of our project tools so you can do some hacking on things yourself and help out if possible.