Creating Releases

Releases

Last time on goblin camp adventure we finally got a functional build running, there would be no better way to celebrate than to make a release on github. There are a couple hurdles beforehand that need to be taken care of. First off the code currently in the master branch does not support the libtcod we have travis building it with. Second off we have no way of automatically uploading releases and finally I'm not even sure if it would work on other machines if it was compiled in travis.

Actually Releasing

To have a binary to release first step is to have a working, running, non segfaulting version of the game. This is already done locally on a test vm but it needs to be in github so we can have travis make it automatically for us. I can't just overwrite the scripts in the master to use the old version so I decided to make a branch that would be in charge of making the releases for the time being. That is until master becomes more stable. Appropriatley I called the branch working-build. I then had to change the build scripts to use the older libraries that we working build needed, after that I had to use travis cli tool to generate the secure key that allows it to push to releases. Except when I used cmake on my machine it would make a pkg directory with all the files inside of it nicely bundled, but when I ran it on travis it stalled it to the user directories. After many hail mary commands I found out that I need to run cmake twice to make that folder so I could put it in a tar. I thought I was done, except when I tagged a branch and pushed the tag to github the release wans't there. So I cleaned up some stuff in the script and pushed it again with a tag and the same thing happened, no release. Except now the first tag I made had one. I honestly don't know why this happened but it was good enough for a first ever github goblin camp binary release. Someone will probably fix it later...hopefully

Removing Boost

Why its problematic

Having boost in the project is a big help since it implements a huge range of useful features and objects. However over the years a lot of these features have been moved into the c++ standard library. Having boost included also makes building goblin camp a little harder across platforms. This lead us to start replacing the boost libraries with the std equivalent.

The Move

Moving to std libraries most of the time isn't a problem since some features of boost are transferred into the standard. So for libraries like cstdint it almost exactly the same as boost/cstdint. To change it all that needs to be done is change the namespace and include statement to use the standard one. One pr after and we use one less boost library. I feel like most of these boost libraries won't be too hard to remove except for the one deeply ingrained in the project.

Goblin Camp Continued

Travis continued

This pr addressed that after a lot of trial and error our travis.yml got quite out of hand. My job was to clean it up and make it look like it was made by someone who knows what they're doing. It was kinda hard to implement since every change I was unsure of I had to commit it and push it just so I can see if it worked. Needless to say this made it take a lot longer than I thought. I also moved the depenencies that were being installed from source and put it into a shell script. This removed the clutter in the .travis.yml and the script could be used by people who also want to build them.

The future

What I spent most of my time on was trying to get an actual playable version of goblin camp running. The boost library it needed was out of date and couldn't be installed through my package manager and when I tried to install it from source it couldn't be found by my makefile. Trying to preserve my sanity I just started a ubuntu 14.04 vm and used their package manager to get all the old packages I needed, and surprisingly it worked.

In a way it is slightly terrifying since now I have no excuse but to work on the code...

First PR

First Internal PR

Goblin Camp has been classified internal so I've been working on that trying to get travis ci working with it. Travis is an automated build system that when you create a branch or a pull request will build the project to check for errors. This makes development easier since people who can't build the project or forget to will still have it built. This is useful to me as a maintainer since its a quick way to see if it is safe to merge into master or just test things without having to go through the trouble of setting up the environment.

Travis CI

All of the build configuration is done in the .travis.yml file in the root of the project. I gave it commands to pull packages that were required from the Goblin Camp as well as try to run the build script. Of course it didn't build since the Boost.Build was horribly outdated and trying to find out how to make it build would required a blood sacrifice or something along those lines. Thankfully it was not in the scope of my issue to get the project to build. I just had to make a .travis.yml that tried to build it. It was pretty simple but I learned a lot about travis, like its free and kinda slow and our build script kinda sucks. It finished off this pull request even through right now it's kinda of useless but I have a feeling that trying to get Goblin Camp to build will be a whole different story.

Arcane Knowledge

Goblin Camp

Goblin camp has recently taken a large set of real estate in my head. Its a perfect storm of challenges and things I understand. The first big challenge was getting this beast to build and spoiler warning, we did. It took us a lot longer than I'd like to admit but what I would like to admit is that I didn't do this alone. A good friend of mine, Tony Sim trudged through the perils with me on our journey to compilation. Which unlike most open-source we worked on it in the same room, using the same computer(mine for the record). This encapsules what I think opensource has the capability for, collaborating locally or globally. This very local open source has its own advantages and disadvantages than over the net. First off you can bounce ideas and try things very rapidly as well as tag out when you're head is going under water. This was especially useful since the only dev environment we had that had the potential to run this was my laptop and all the changes we made were instantly visible to both of us.

Hacking through

To try and get it compiled we mostly just threw commands around and installed packages with no regard. Exporting environment variables, reading posts, trying not to give up were all things that we did. Every time we went through this we would gain maybe 1-10% extra compilation then it would crash again. Telling us errors about not being able to locate packages that we're removed from the libraries it uses, saying it can't find packages we have, that our packages are out of date, our compiler is out of date, it can't find headers from our packages, it just went on and ooon. So we hacked away at it for a good few hours or days, I couldn't tell, when you've fallen into the rabbit hole time gets distorted.

Success?

After the whole ordeal we had it at 100% compilation and we thought this was it!!!... then it failed at linking. I have never been more discouraged by a single program. The problem was in a cmake script. It was an easy fix, but hard to find. After it compiles AND links I thought the build script didn't work, in the instructions it says it would put it in the build folder, but I found it in the src or root I can't remember. The moment of truth was finally upon us. We have slain all the enemies the compiler threw at us. We found the sacred texts that allowed us to build every dependency. We shacked the objects together. We were victorious! Our prize? "Segmentation Fault". No GUI no nothing, just "Segmentation Fault".

Pull Request

For my pull request I updated the travis.yml with all the environment magic we struggled to find to get some automated building for it, even if it seg faults. On our journey we found a lot of issues that were made into bugs and then into pr's. Even though we both worked on it, it was easier for one of use to commit the changes to a branch and merge it. My issue was updating travis which is something I was familiar with and I also had a pull request that compiled a package from source. On the horizon we're probably going to faze out the outdated libaries and try to get it to not seg fault, who knows maybe this project is cursed but now I bear the mark of the curse and I've dived too deep to come up for air now. Not when I've gotten this far.

Diving Deeper Into Open Source

Recovery

After the frantic nature of finding projects, finding bugs, building projects, and making pull requests I needed a little break. So I have been looking into projects that might find interesting. A few that caught my interest were Dark Chatter, Creative Collab and supernova from fellow students.

Dark Chatter

Dark chatter is interesting to me since seems like it will rely on low level stuff like constructing packets and it will help me understand more on how wifi works.

Creative Collab

Creative collab also expressed interest in doing the project in mostly as a backend server that has public end points. It would be neat to learn how to create a server to host an api that anyone can use.

supernova

Super nova caught my interest not because of the idea but more of the language choice. I have never used rust and learning it through open source seems like a good way to find out about the language.

External Projects

Goblin Camp

Goblin camp is kind of like a open source dwarf fortress and it was forked by a class mate with the intention of parallelizing it, since the original is still running on a single thread. As of right now I am stuck in the same slog that kept me from trying other projects, getting it to build. But since I have a little more leeway with this due date being more lenient than the hacktoberfest one I think I will try to push through to get it to work. The project is also been abandoned for a couple years so it might take some time to get it all working.

Path Forward

Now I'm going to try to dedicate some time to building the projects I'm interested as well as seeing what I can contribute. Maybe even make some issues, who knows, I feel more confident after hacktoberfest and excited to apply all that I learned going forward.

Hacktoberfest Review

Overall Thoughts

Overall I think hacktoberfest was a neat way to dive into the opensource community. I also found it very frustrating finding a project that I liked or could build. Since there were many times where I found a neat project but couldn't build it and didn't want to waste hours figuring out why. I also found the amount of repositories just made for hacktoberfest pull requests annoying since they would saturate the hacktoberfest tag with what I thought was not a real project, more like a collection of code. Even though all my complaining it is still my fault I didn't contribute to some projects I found interesting. I didn't leave enough time to them and greatly underestimated how long just getting something running would take. Moving forward I'll take this into consideration when I want to work on a project and give my self at least twice the amount of time I would think it would take.