Changes between Version 73 and Version 74 of BuildSystem


Ignore:
Timestamp:
12/15/12 22:31:13 (7 years ago)
Author:
welberge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BuildSystem

    v73 v74  
    1717 
    1818  
    19  
    20 == Build philosophy == 
    21 It is often necessary to (re)build projects, even by persons who didn’t develop that project. Since many different tools are being used, we have to agree on a number of basic conventions and procedures. 
    22  
    23 * We do not assume that everyone will be using the IDE or any IDE at all. But we do require that a project created and developed, say, by means of Netbeans or Eclipse, can be (re)build without any of these tools available. 
    24  
    25 * Since we have to use some common build tool, we have agreed to use [[http://ant.apache.org/|ant]] as that “common” minimal platform. 
    26  
    27 * In principle every project lives in its own directory, containing all relevant source code, test code, project specific data, library files needed by that project, project documentation, etcetera. We have a preferred [#directorylayout standard layout] for the directory structure inside a project. A project also contains an ant buildfile (build.xml) and usually also a build.properties file. We require that we can (re)build and run a project using ant, without any reliance on development tools that might have been used to develop the project. To be clear: we don’t want to install JBuilder or Netbeans or Eclipse or whatever just to build and run your project. The ant file can be either a simple “standalone” build file, but the preferred way is to use a very small build file that just links to our shared build file (see [#directorylayout layout]) 
    28  
    29 * We have a limited number of shared projects, all of which are available from our GIT repositories: 
    30   - There is a “project” called hmibuild. It contains the shared ant build files. You must have this project in order to use our build system. 
    31   - Shared software is available as source code or as compiled jar files. Most projects use the precompiled library (e.g. jar) files, which are kept in a project’s lib directory. (For tools like Eclipse or Netbeans you 
    32     must do some configuring in order to use these library files, see below). We use a tool called [[http://ant.apache.org/ivy/|ivy]], used by our build files, for easy version management of lib files that relies on our web repositories (hmirepo.ewi.utwente.nl, asap-project.org/repo). Basically, when you type “ant resolve”, then ivy will copy the library files needed for your project into the lib directory of your project. What will be copied is derived from a project file called “ivy.xml”. 
    33   - There are a few “projects”, like !HmiResource, that contains just “resource” data of all sorts, that is shared between projects. For instance, BML scripts, data for 3D scenes and avatars etcetera lives here. Usually, you can obtain such data also from the web repository, in packaged jar format. Sometimes, you want to actually see and modify that data, and in that case you will need to check out the relevant resource data from the git repositories. 
    34   - Projects import and export class code and data in the form of jar or zip files. Whenever viable, there is no sharing of source code (one exception is C++ code in Linux, which typically has to be recompiled on each system). This ensures that every project can be built stand alone, after importing the necessary library files. 
    35  
    36  
    37 == Why dependency management == 
    38 The contents of lib directories consists of jar les and/or \dll" or \so" les 
    39 that are necessary for compiling and running the project. The basic strategy 
    40 is that inter-dependencies between projects are via import/export of library 
    41 jar files, in preference over direct source code dependencies. Of course we 
    42 have to face the problem of project versioning. We have stable release versions 
    43 of projects, but also less stable daily releases and alpha versions. Here we have some 
    44 conventions and rules. For instance, we do not want a stable release version 
    45 of project X to be dependent on an unstable alpha version of project Y. The 
    46 other way around, so an alpha version of X dependent on a release version of Y 
    47 is OK of course. It will be clear that manual version management is not a good idea: lot's of work,  
    48 and error prone. Instead, we use a dependency manager, 
    49 [[http://ant.apache.org/ivy/|Ivy]]. 
    5019 
    5120=== How does it work? ===