Skip to main content

Building Mozilla Firefox

Trying to build Mozilla Firefox was such an experience. I have mixed feelings about if it's a good or bad one but nonetheless, I will share my experience.

I built mine on my macbook pro running version 10.12. The things I had and/or installed were the following:
-Terminal
-Xcode
-Homebrew
-Python
-Rust
-Mozilla Firefox Code

Downloading the Mozilla Firefox code was the simplest part, it took long but it was simple. The real challenge was trying to compile the code. The amount of time it takes to successfully build it is over an hour. Imagine reaching the end of the compilation, seeing that there is an error, and the compiler stopping. This was the case for six days! It took a long time to get this working.

At first I thought there was permission issues so I tried building with sudo. This was not the right thing to do as it messed up my future attempts to recompile the code. I was told to remove the object directory and start again without sudo.

The next thing that was suggested to me was to install or reinstall Rust. I thought I installed it already but it turned out that i didn't. I installed it and tried recompiling again. Like all the other times, it would go on and on and on with complete failure.

It turned out that I didn't actually have rust installed so I went ahead and installed it. I tried running again and I still got nothing. The errors I was getting were:

error: 'stdlib.h' file not found

/usr/local/Cellar/llvm/5.0.0/include/c++/v1/wchar.h:119:15: fatal error: 'wchar.h' file not found, err: true

/usr/local/Cellar/llvm/5.0.0/include/c++/v1/stdlib.h:94:15: fatal error: 'stdlib.h' file not found, err: true

/usr/local/Cellar/llvm/5.0.0/include/c++/v1/stdlib.h:94:15: fatal error: 'stdlib.h' file not found, err: true

After giving up and turning to my teacher for help, a student who literally just solved the same issue before my eyes was just standing there. The teacher asked him to help me and he said run this simple line in terminal. 

Xcode-select --install

I said to him, I already have terminal, he said, "So did I, but this worked for me." After running it, it prompted a gui dialog asking me to accept and install some things. After that, I deleted my object folder for one last time and I recompiled. Sure enough, after an hour, it compiled.

The odd thing is that even though it successfully compiled, the amount of warnings that were flying by in the terminal was significant. There are so many warnings. It's unusual to see something work with hundreds of warnings, but it works so I'm not complaining.

Overall, it was a good experience and I couldn't have done without my classmates and teachers help. They were a crucial part in my success. Working on an open source project with a community is the best way to work. Individual progress can be achieved, but community is greater by a long shot.

Comments

Popular posts from this blog

Documentation

Documenting everything is extremely important. It gives everyone the information they need whenever they need it. Github makes it very easy to have beautiful pages written in markdown rendered automatically. It's nice and easy to do. Creating a README in the root of the project is common practice and is even automatically rendered when the project is open in Github, under all the file names. I've been looking at quite a few different projects and they all have README files. It usually includes an introduction to the project, how to set it up, how to run it, how to contribute to it, major credits to people, etc... Essentially, it holds important information about the project that anyone has access to. Along with the README file, we can comment on our actual code so hackers who read the code can know what does what. It allows the creator to recall what they wrote in the past and it invites new people to understand what has been written. It is really important that comments are

Second Attempt At Fixing Open Source Bugs

In my second attempt at fixing open source bugs, I want to prove that I have grown from the first attempt. My first attempt was fixing a single bug, requesting a pull request, and getting approved! My goal this time around is to work on more than one bug, I plan to work on 2-3 and my ultimate goal is to get all of them approved! There is no better satisfaction than getting approved!  Since I was working with Mozilla projects before, I decided to stay in that bubble and work on Thimble/Brackets. I have currently asked to work on a couple bugs like this  and this  and once I get the okay to do so, I will begin to try to fix them. As of right now, I am still researching for more bugs to work on, but at the time of this blog post, I do not have any backups.  Due to the strike, a lot of things are altered in my schools semester. Surprisingly, all my teachers were very accommodating and they dropped tests and assignments and overall, it's making the end of the semester less over

Automated Testing

Automated testing is a very useful feature that is simple to implement in any open source project. It allows the testing to be automated to ensure that nothing will break when things are changed. In the open source world, code is changed quite often so having automated testing can make it easy to track and manage errors and we can know if the code is properly written to pass the tests. Overall, it is very beneficial in open source programming. Travis CI makes it very easy to link your Github page and the repos on it. It is very easy to get started and I would recommend it to everyone! I always used to do my testing by outputting the results and comparing it with whatever I had in my head, now, it does it all on it's own.