Creating a "binary release" from a compiled source code repo

Get help with installing and running the Cafu Engine here. This forum is also for general questions and discussion of all aspects regarding the Cafu Engine.
Post Reply
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:
Creating a "binary release" from a compiled source code repo

Post by Carsten » 2014-04-25, 23:53

Hi all,

I just committed a change to the Tools repository (https://bitbucket.org/cafu/tools) that adds a very simple script (deploy.py) that calls a new function CopyRepoToBinary().

Source code of deploy.py:

Code: Select all

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import os, subprocess
from common import CopyRepoToBinary


# This is a very simple test for the newly written functions in `common.py`.
# It essentially duplicates (some of) the functionality in `make_binary.py`,
# but in a manner that is easier to re-use, to maintain, and to adapt to new
# purposes.

# Please see the documentation of this function in `common.py` for details.
CopyRepoToBinary("../Cafu", "Cafu-copy-test")
The documentation of CopyRepoToBinary() (in common.py):

Code: Select all

Creates a "binary release" directory `DestDir` from a Cafu source code
repository `SourceDir`.

The directory `SourceDir` must be the root directory of a Cafu source code
repository checkout in which in which all programs and libraries have already
successfully been built, all maps files have already been compiled, all
texture images are present, etc.

The directory `DestDir` is newly created and intended to be used as a public,
binary release of the Cafu Engine and games developed with it (possibly after
further packaging, e.g. as a zip file). An exeption is thrown if `DestDir`
already exists.
Example usage:

Code: Select all

d:\Dev>dir
 Verzeichnis von d:\Dev

20.04.2014  23:15    <DIR>          .
20.04.2014  23:15    <DIR>          ..
25.04.2014  14:27    <DIR>          Cafu
25.04.2014  23:12    <DIR>          Tools
[...]

d:\Dev>cd Tools

d:\Dev\Tools>python deploy.py

d:\Dev\Tools>dir
 Verzeichnis von d:\Dev\Tools

25.04.2014  23:12    <DIR>          .
25.04.2014  23:12    <DIR>          ..
25.04.2014  23:42    <DIR>          Cafu-copy-test     # newly created by deploy.py
23.10.2013  20:35                79 .gitattributes
23.10.2013  20:35                 6 .gitignore
23.10.2013  20:35             2.305 BalanceDetailMap.cpp
25.04.2014  23:13             3.625 check_source.py
[...]
The newly created directory Cafu-copy-test contains a stand-alone, self-contained, binary-only edition of Cafu, ready for release or further processing (e.g. packing into a zip file, upload to FTP site, etc.).

My further plan for the scripts in the Tools repository is to further split the well-working, but rather monolithic functionality of the `make_binary.py` and `make_source.py` scripts into smaller functions that can act independent of each other, so that eventually a set of functions results that is easy to use and (re-)combine, so that deployment tasks involving the Cafu Engine can easily and robustly be solved. :up:
Best regards,
Carsten
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: Creating a "binary release" from a compiled source code

Post by Carsten » 2014-06-01, 10:20

Hi again,

I just committed another change to the Tools repository (https://bitbucket.org/cafu/tools), and that change breaks the above described functionality.

However, don't worry: Nothing is lost, and it is only my addition of new functionality that temporarily breaks the backwards-compatibility to the command-line interface described above. In fact, I use the deploy.py script as a testbed for all sorts of functionality around deployment and "continuous integration" (CI) matters of the Cafu engine, whereas the other scripts in the Tools repository are managed more carefully and kept much more stable.

The new functionality, btw., involves the automatic update of our Lua scripting reference documentation (much of it is automatically derived from its C++ implementation, which is one of the virtues of the component systems), and the automatic uploads of the C++ and Lua reference documentation to http://docs.cafu.de/c++/ and http://docs.cafu.de/lua/ :wohow:


My plan is to further use the deploy.py script as an experimental platform where all the individual pieces for deployment and CI are tried out, so don't worry if similar changes occur again once in a while. Eventually, all newly developed features will be re-shaped into a stable tool for all "meta-management" of the Cafu source code. :up:
Best regards,
Carsten
Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests