Category Archives: GSoC 2022

Google Summer of Code 2022

Future automatic releases in LibreCAD3 – Final Report: GSoC 2022

Posted on by
3

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.




A brief look at the future automatic releases in LibreCAD3: GSoC 2022

Posted on by
4

Hi everyone! I’m Cristian and I’ll tell you about my project, which intends that anyone who wants to try out the current state of LibreCAD3 can do it as any other application. You should be able to download it as a ‘.exe’, or if you are a Linux user, get it as a ‘.appImage’ or as a ‘snap’ in the Snap store.
The key parts of this proposal are building, packaging, testing and deploying:

  1. Building: When I started getting involved with LibreCAD two months ago, I first started with the Windows installation. The wiki installation was outdated and sometimes confusing for a non-experienced dev. 
    Fortunately, Florian was able to patch all the errors surrounding the installation, and so I finally installed it successfully. After this “week-long installation”, I committed to writing a batch script to install it automatically, which can be consulted in the installation wiki. 
    Also, I updated the Windows guide so anyone with a bit of experience following guides can get it built. The next step will be installing it for Ubuntu. Right now the wiki only covers a long line of packages to be installed with apt. I’ll try it out and update the wiki with additional steps if needed.
  2. Packaging: After LibreCAD3 is built, in Windows it needs to be packaged with QT and Conan dependencies. After having everything together, an extraction script will be needed so that when the ‘.exe’ is executed, its contents are moved and some requirements like PATH variables are appended.
    For Linux, It’ll have to follow AppImage’s & Snapscraft Documentation to get them packaged.
  3. Testing: It’ll have to test the packages before deploying. For AppImage and Snap, some programs can do exactly that. For Windows, It can try to install it from the ‘.exe’ and see if it doesn’t fail.
  4. Deploying: Finally, with all the packages tested, The ‘.appImage’ and ‘.exe’ will be uploaded to Github as a release, while the ‘snap’ will be uploaded to the Snap store.


Hope you like the proposal! If you have any new ideas or improvements on how to tackle this goal feel free to reach me out in Zulip-Chat(@CRiSTiK24) or leave a comment down below!

You can check the complete proposal (12 pages in pdf) and more here:
Link to Librecad’s Gsoc page in wiki