Hola amigos,
Google Summer of Code results were announced on 27th April, 2015 and I was one of the selected students. After the results the “Community Bonding” period starts till 25th May, 2015.
What is Community Bonding?
In Community Bonding, we get to know more about the project, mentor(s), other developers, etc. It is a one month period where you get enough time to go through and understand the codebase, set up your accounts and local repositories, discuss about the project plan and strategy, look into similar implementations and get to know the awesome people working to make the project better. You are now one of them too 😉
As soon as the results were out it was something different feeling altogether. For my organization “The MacPorts Project” there were 3 students selected, including me. My Mentor, Clemens Lang, sent out official emails (Google sends official selection mail too) to us about being selected and what we will be doing ahead in community bonding period. I went through the links and what was planned ahead and took no time (excitement level was off the charts) to thank him and the community for helping us out during the pre-application period to better understand the project ideas.
First Meeting: 29th April, 2015
We (My Mentor, Clemens and I) had our first official project meeting on FaceTime the next day itself, it was something new that we had tried having meetings on FaceTime. In this meeting, we got to know each other and we discussed a tiny bit about our project and scheduled weekly meetings. At first FaceTime was lightning fast for discussions, but from the second meeting onwards we stuck to the same old IRC :). Well IRC since, it was easy to go through the previous logs and others can also participate in the discussions.
Second Meeting: 4th May, 2015
In this meeting, we went through the MacPorts (MP) codebase. neverpanic (My Mentor, Clemens) walked me through the complete macports codebase. We discussed which file provides and does what and which were the files we would have to look into and discussed about them in detail. We did skip a few files as they weren’t required at the moment and we would go though them when required. Going through the code yourself and having someone guide you with experience makes a huge difference. I tried to go through the codebase and could actually understand small portion but with the help of a mentor this process was completed in around 2-3 hours (~70-80% of codebase).
Then we also discussed where we would add the libsolv along with MP. Ideally, it would be under vendor/ directory. But then libsolv depends on cmake (a cross platform build system) and cmake isn’t distributed along OS X, Xcode CLT (Command line tools) or MacPorts. So have kept that for future discussion, whether cmake would be a pre-requisite for MP (this would mean more dependencies for MP – curl, expat, zlib, bzip2, libarchive) or should we convert it to autoconf build system or pre-generate cmake-based build system along with MP.
We went through the MP codebase following the path of the command “port install foo”. MacPorts is written in Tcl (pronounced “tickle”) and there exists some part of C. First we looked into port/ folder which contain the files port.tcl, portindex.tcl and portmirror.tcl. port.tcl is the file that is basically executed when we do something like “port install foo” or in general “port “. For the users convenience we run port without the .tcl extension i.e. “port install foo” and not “port.tcl install foo”. Files under port/ mostly deals with the front-end presentation, command line parsing and resolving expressions.
Then we moved to the core of MP i.e macports1.0 folder. Inside this macports.tcl takes care of everything and is the most important and also the largest file in MP base. This is also the file where the dependency calculation happens, hence the main file to work on since we need to work on “dependency calculation” and we will probably call libsolv functions from here. As it is already a huge file, we might probably move the new functionalities to another file, probably dependency.tcl or similar.
To install a port there exists a Portfile which defines a set of rules and metadata describing the package and how to build it. MP create a new Tcl interpreter and runs the portfile. Inside this sub-interpreter the files inside port1.0/ are executed during the respective phases like fetch, verify checksum, extract, patch, configure, build, destroot, test, archive and install. This makes the life of a Portfile maintainer easy as they would only have to configure the URL and filename to download, other things are taken care of by the port1.0/ files.
package1.0 deals with if there exists a pre-built binary archive on our mirrors and how to fetch and use these instead of building the port on the users system.
To keep track of the installed ports, etc MP uses a SQLite DB. The code that deals with handling this DB is under cregistry/ and registry2.0/, where the latter is more object oriented and east to use.
pextlib1.0/ contains the extensions for MP’s Tcl. E.g. MP’s Tcl comes with a “curl” command which internally uses the libcurl to fetch files. Various Hashing algorithms are also found under pextlib1.0/ which is used by MP to verify the checksum of the fetched files by running the checksum on the file and compare with the checksum given in the Portfile by the Portfile maintainer.
Then we had a Q&A session and we cleared some doubts regarding cmake and build system and some parts of Portfile.
We were waiting for other students to respond before we move forward with creating macports.org account for using svn. I started trying out svn on assembla.com. We also discussed about svn (C-VCS) and git (D-VCS) and concluded our second meeting.
Third Meeting: 11th May, 2015
Software Engineering exam tomorrow, but anyways the paper will be as usual difficult so moving to some Open Source 🙂
I went through the libsolv code and as neverpanic had also sent some links over mail to look into. I couldn’t cover the whole thing but still I got a brief idea of what the libsolv does.
In this meeting, we tried to compile and build libsolv on Mac OS X. As expected there were errors, in linker to be precise. neverpanic created a port with patches to be made to the CMakeLists.txt which is somewhat similar to ‘Makefile’. We also pushed the patch upstream and then moved to vimrc. As I was having some problems using vim so we set up a clean vimrc and then concluded the meeting.
Fourth Meeting: 18th May, 2015
The other students had replied regarding their handle for macports.org ID and neverpanic had mailed the MacOSForge admins requesting for the account creation. We actually rescheduled this meeting the next day i.e. 19th May, 2015.
Now, I had gone through the libsolv and understood the different data structures used and what the functions do and how they work. Thanks to neverpanic’s libsolv Port, man pages libsolv-bindings, libsolv-pool came handy and were very helpful. We also went through the pysolv (Python bindings for libsolv) example as it was easier to understand what the modules do and how.
At the end of meeting, we had covered almost 650 line of code, many lines were skipped too as they were not necessary at the moment.
Community Bonding period ends on 25th May, 2015 and Coding period starts but we had another meeting planned on 25th May, 2015, where we finished off with the pysolv example and moved to further planning of the project. This will be covered in the coming posts. 🙂
P.S: I was lazy to re-check the above. So please feel free to point out the mistakes and I’ll look into it and make sure to correct them.
Let the Windows be open, and feel the Freedom.
Jackson's Blog 