Outpost Universe Forums

Off Topic => Computers & Programming General => Topic started by: Hooman on October 23, 2019, 03:50:51 AM

Title: If They Come, How Will They Build It?
Post by: Hooman on October 23, 2019, 03:50:51 AM
I read an interesting and slightly cringeworthy article about taking 2 weeks to get a new developer on board:
If They Come, How Will They Build It? (http://web.archive.org/web/20071013071537/http:/www.hacknot.info/hacknot/action/showEntry?eid=97)

This article reminded me of the use of NASM in the OP2Internal project (formerly ForcedExports), which had no documentation about how to build it. At best, it had some NASM build rules in the project file, making reference to a non-existent tool on new developer machines. I remember being asked a few times how to build that project.

I was pleased to read about the suggestion of having automated builds. The build machine setup effectively provides at least some level of documentation on how to setup a development environment. Hopefully we've progressed in that regards for the projects where automated builds have been implemented.
Title: Re: If They Come, How Will They Build It?
Post by: TechCor on October 23, 2019, 11:27:32 PM

Most projects I've hopped in on build without any problems. Maybe need to set up some SDKs, but the error messages usually tell the story. Dev servers are usually shared and already set up to log in remotely. I work in a different field though.

The biggest problem I run into is simply poorly designed code. Nothing like seeing a web of global objects all accessing each other, then trying to figure out how to add your new module to the stateless morass. Not unusual to find the previous programmer has long since left the project, and I have to figure it out on my own.

Yeah, I'm currently refactoring a big project. ::)
Title: Re: If They Come, How Will They Build It?
Post by: Vagabond on October 23, 2019, 11:36:52 PM

Funny that you brought it up as I was reading from an x86 Assembler book recently and was wondering why we didn't use MASM for the assembly in OP2Internal as it would then be built into Visual Studio and not require a special build step or downloading NASM.

I think outside of NASM, we have been fairly good about simplifying the build process and standardizing the project settings recently. Although yeah, our documentation is lacking.

Title: Re: If They Come, How Will They Build It?
Post by: Hooman on November 02, 2019, 02:32:08 PM
@TechCor: I think the project dependencies, such as SDKs, are one of the bigger concerns when it comes to building a project on a new machine. Having a Docker image or virtual machine setup with all dependencies pre-installed can be a big help to get going on a project. Also helpful is an install script which knows how to download and install all the needed dependencies, and will do so with correct versions that are compatible with the project. Even better is when the build system knows to do this automatically for a new machine, and can do so cross platform. For small largely self contained projects, these are course not big issues. Though as dependencies grow, and the differences to download and install them increases, the more it becomes an issue.

Btw, what language are you working in for the refactoring project?

@Vagabond: My understanding was that MASM was also a separate download from Visual Studio (at least it used to be). I wasn't aware of any built-in support for it. Previously I used MASM for toying with assembly code on Windows. Eventually I switched to NASM, which works cross platform. The choice was likely made because I was more used to using NASM at the time I started that project.