Hello everyone! This week is the last one for GSoC22 and I’m here to announce to you all the progress done in my project.

You now can download LibreCAD 3 in windows and Linux! Thanks to GitHub Actions and several changes to the codebase, when entering in any “Librecad3 builders” run in the actions tab of my clone of the repository, for example, this last one ( https://github.com/CRiSTiK24/AddCI-CDLibreCAD_3/actions/runs/3003305310 ) you will find as artifacts installers or packages for Windows and Linux.

What is new?

I’ve moved this part to https://github.com/LibreCAD/LibreCAD_3/wiki/Installation. As a summary on the current status, the artifacts are available as artifacts in my own repo at the Github Actions tab, and once it gets merged, in the main repo tab. Also, since LibreCAD3 is unstable, I’ve considered that i’d be better to not put it in the snap store.

Next, I’ll provide a list of the different technologies I’ve learned during my project, and some links to my work ( dev log, wiki, etc ).

Tools used:

CMake/CPack: We were taught to use GCC at university, yet Cmake is another kind of beast. At first, I was hesitant about how overcomplicated the CMake files and command line arguments looked, yet little by little I began to appreciate how many tools it was integrated with (the snap, appimage, and cpack were able to automatically deploy into the install folder without much complication). Also, once I started messing with the interactions and different directories in C++, I saw how easy was to add a library without having to put in the C++ file the exact location of it.

C++ & Qt: C++ is the main programming language taught at my university, but still there was a lot of new keywords and code structure that was totally new to me. Either if it was “External”, or the “newclass : inherited class”, I had to try many times different combinations of code until one of them worked and let me understand the logic of that file. Meanwhile, Qt was well documented, and other than the huge collection of types and functions (There is really a necessity for that many strings) it was quite fast to figure it out since I didn’t have to modify code related to the GUI.

System call tracers and debuggers: At university, we aren’t taught how to use them, so my usual method used to be lots of prints() everywhere. However in a project this huge, It would have been impossible to detect missing files of the package without the call tracers (strace in Linux). Also, the debugger allowed me to have a way to set the absolute path to the exe from the Graphical subdirectory using Qt Methods to the other subdirectories. Without using the Visual Studio Debugger it’d have been totally impossible to find the way.

GitHub Actions and Snapcraft YAML: Though its indentation made me have to rewrite the code more times than I’d have liked, It wasn’t much different from a regular bash/batch file with some special way to pass the arguments. What I found harder was the way to use GitHub Actions variables. Foreign actions like Checkout set some helpful variables like the path towards the cloned repo, still, in the documentation, there were many ways to access it, but only the way it’s right now worked for me.

Bash and Batch: We were taught the basics in the university, so it didn’t feel very strange. It was mostly planning on the more effective way to get a tool (like visual studio compiler) that would last. Thanks to GitHub actions I was able to get tools like Qt from a foreign action, instead of having to use a strange URL that could disappear in little.

Conclusions:

I’ve certainly learned a lot this summer. One of the things that I will remember is how many posts with similar issues to the ones I faced were on the internet and how many of them remained unanswered or used a workaround that didn’t work for me. It made me think of how much of the big software that we regularly use and consider rock solid is probably much more fragile than we really think.

The other one is how entering through an opportunity presents many more. At the GSoC summit at the beginning of the summer, we were presented with Google Developer Student Clubs. There weren’t any in my city so I took the opportunity and this year I’ve been selected to begin a chapter at my university. At the same time, I began taking my LinkedIn seriously, and it made me receive a message to participate in a week-long Huawei formation called “Seeds for the Future”.

There are some ideas that I wrote in the original proposal that I’ve not implemented because I thought they wouldn’t be a good idea. The main example is uploading every snap to the snap store automatically. Since LibreCAD3 is still experimental software, I thought that if someone was using a functional snap they wouldn’t want an automatic update to break their version just because one of the devs tried out a new change. Also, the proposal had some extra steps for testing, though after being involved with the building of the snap and appimage I’ve seen that they are so hard to get built that just getting there is a pretty good test. If it needs more tests I’ve checked back the proposal and using “appimage-testsuite” on the AppImage seems the best option.

So as the last paragraph, I’d like to thank the mentors and everyone else in Zulip that helped me out. I’ll try to stay active so if anything related to my work has an issue I can lend a pair of eyes.

• Links:
• Project page: https://dokuwiki.librecad.org/doku.php/gsoc:gsoc2022
• Dev log: https://dokuwiki.librecad.org/doku.php/gsoc:log2022
• Original proposal: https://dokuwiki.librecad.org/lib/exe/fetch.php/gsoc:gsoc2022.pdf
• Project plan: https://dokuwiki.librecad.org/doku.php/gsoc:plan2022
• Project’s Repository: https://github.com/CRiSTiK24/AddCI-CDLibreCAD_3
• Project’s PR: https://github.com/LibreCAD/LibreCAD_3/pull/394
• Extra documenation for devs about any future changes to CI/CD: https://github.com/LibreCAD/LibreCAD_3/wiki/Continuous-Integration