Changes between Initial Version and Version 1 of Programming/Python/OrganizationOfBuildEnvironmentScripts


Ignore:
Timestamp:
Feb 19, 2016, 12:05:37 PM (6 years ago)
Author:
Vijay Varadan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Programming/Python/OrganizationOfBuildEnvironmentScripts

    v1 v1  
     1= Organization of Build Environment Scripts =
     2Jan 04 2016
     3
     4I use [https://www.mercurial-scm.org/ mercurial] for version control. There are multiple repositories, typically 1 per game or product. If a game or product is complex enough, it will warrant multiple repos. The layout of the "sub-repos" within a project is fixed and the developer needs to ensure adherence to the layout to get the project to build. The need for multiple repos within a single project stems from having teams with different needs and schedules working on various pieces. E.g. artists and animators work on assets on a different schedule and publish content to their own repo. Developers, QA and automated build & test systems can use placeholder assets initially and subsequently integrate the final assets when they are ready. This also provides the flexibility of using a different version control system for art and sound assets which is better suited to binary files e.g. [https://www.perforce.com/ Perforce] rather than mercurial.
     5
     6Coming to the actual layout, it looks something like this on Linux and MSYS2:
     7
     8{{{#!html
     9<pre>~vijay
     10    |-<span style="color: #800000;">.bashrc [1]</span>
     11    |-work
     12      |-repos
     13        |-0
     14        |-1
     15          |-private
     16            |-bin
     17              |-<span style="color: #0000ff;">devenv.sh [3]</span>
     18            |-developer
     19              |-bin
     20              | |-<span style="color: #800080;">devenv.sh [4]</span>
     21              |-project1
     22                |-<span style="color: #ff6600;">project1.sh [5]</span>
     23            |-artist
     24              |-bin
     25              | |-devenv.sh
     26              |-project1
     27                |-project1.sh
     28            |-vijay
     29              |-bin
     30                |-<span style="color: #008000;">devenv.sh [2]</span>
     31</pre>
     32}}}
     33
     341. [[span(style=color: #800000, .bashrc ![1])]] contains the startdev() function
     351. [[span(style=color: #008000, devenv.sh ![2])]] user specific overrides go here
     361. [[span(style=color: #0000ff, devenv.sh ![3])]] common to all projects, users and roles, like build / install directories
     371. [[span(style=color: #800080, devenv.sh ![4])]] role specific settings go here
     381. [[span(style=color: #ff6600, project1.sh ![5])]] project and sub-project (if any) specific settings go here
     39
     40The way a build environment for a project is setup is to invoke a function, say `startdev()`, from [[span(style=color: #800000, .bashrc ![1])]]. This function ensures that the local repository instance (1, 2, etc) and project are set. It then dot-sources the user's [[span(style=color: #008000, devenv.sh ![2])]] script which internally dot-sources the main [[span(style=color: #0000ff, devenv.sh ![3])]] script in private/bin and the role specific (in this case developer) [[span(style=color: #800080, devenv.sh ![4])]] script. The role specific [[span(style=color: #800080, devenv.sh ![4])]] dot-sources the project specific script, [[span(style=color: #ff6600, project1.sh ![5])]]. At every stage, the sourcing script can override settings in the sourced script. This keeps the main line settings separated out from the overrides. Similarly, role and project specific settings are separated out into their own files.
     41
     42There are a couple of things that are missing from this setup. The first is the lack of per machine overrides. These would be useful if, for example, a developer worked on 2 computers side-by-side or even virtual machines; one for debug builds and another for release builds or one for server code and one for client code. The second is that all projects have settings stored in sub-folders under each role; as you can see from the example above project1 has its build environment scripts split up, under artist and developer folders.
     43
     44I've chosen not to address either of the issues at this time, because the per-machine overrides are easy to add when I'll actually need that feature in the future - it's only at that time I'll know the real requirements. Essentially, [https://en.wikipedia.org/wiki/You_aren't_gonna_need_it YAGNI]. As for the second issue, while it would remove clutter from the per-role folders and consolidate the files under each project, I haven't felt a need to change it at this time since the number of projects is realistically rather small. Once again YAGNI applies, and I can revisit and easily rejigger the organization without too much hassle.