Simplifying the install script

Now that we’ve managed to remove the need to compile Apache along with Jaxer, changed the configuration to use more Linux-like paths, and created a systemd script for starting and stopping the service, it means that we can now focus on getting Jaxer to install with a single script.

Until now we’ve broken the script up into three parts, install Apache, compile Jaxer and then move the resulting files where they need to be on the system for install. Now we only need to compile and then move the files where they need to be for install. So it basically means that we can concatenate two out of three of our previous scripts into one script and then be able to run that to install.

So right now the single install script is about 460 lines of code. And to be honest most of that script doesn’t look like it needs to be there. I got a little ahead of myself and starting removing lines in the script that didn’t need to be there, and got the script down to 260 lines of code, and while the script was able to compile and install, something about the final settings or a change somewhere caused Jaxer to throw an error in ParseStart.js because the Jaxer binary wasn’t reading configApps.js on initialization.

So it looks like I need to go back and be a little more methodical about cutting down the size of the script and testing one thing at a time. So right now I’ve gone back in my Git, and I’m testing to find the specific version of the script that was able to go from a fresh install to a complete environment and make a commit comment that makes it very clear that that is the working version.

From where to go from there, it’s kind of up for consideration. My next intention is to start documenting and attempting to simplify the server-side framework and when doing so, having the install script as simple as possible will help a lot as it reduces the amount of guess-work needed when encountering a problem. I can know that I’m working with a specific set of static files that are located in the framework folder.

That being said, even if the install script is still a little messy, effectively what I’m doing is copying that static folder into the install as well. So it doesn’t create that much confusion, but it does feel like I would be getting ahead of myself and moving on to the next step when there’s still issues left with the current step.

So it seems more like time management than priorities. I’m eager to get into the server side framework and start documenting and simplifying what I can, but if I methodically take a little bit of time on the install script, then I can approach the next step without having to worry too much that about having to go back and mess with the install script too much at a later time.

So right now identify the script that is able to install in one go. Identify and isolate the areas that I think could be removed. Test each one of those conditions separately, and then move on from there once I have the results from those tests.