Changes between Version 33 and Version 34 of BuildSystem

12/04/12 14:40:34 (7 years ago)



  • BuildSystem

    v33 v34  
    99 * make it easy to release new versions of our own modules 
    1010 * make it easy to use, in module A, the current latest compile of module B, instead of the released version of module B 
     12== Build philosophy == 
     13It is often necessary to (re)build projects, even by persons who didn’t 
     14develop that project. Since many different tools are being used, we have to 
     15agree on a number of basic conventions and procedures. 
     17* We do not assume that everyone will be using the same development 
     18toolkit or any toolkit at all. But we do require that a project created 
     19and developed, say, by means of Netbeans or Eclipse, can be (re)build 
     20without any of these tools available. 
     22* Since we have to use some common build tool, we have agreed to use ant 
     23as that “common” minimal platform. 
     25* In principle every project lives in its own directory, containing all relevant 
     26source code, test code, project specific data, library files needed by that 
     27project, project documentation, etcetera. We have a preferred standard 
     28layout for the directory structure inside a project. A project also contains 
     29an ant buildfile (build.xml) and usually also a file. 
     30We require that we can (re)build and run a project using ant, without 
     31any reliance on development tools that might have been used to develop 
     32the project. To be clear: we don’t want to install JBuilder or Netbeans 
     33or Eclipse or whatever just to build and run your project. The ant file 
     34can be either a simple “standalone” build file, but the preferred way is 
     35to use a very small build file that just links to our shared build file. (See 
     38* We have a limited number of shared projects, all of which are available from our GIT repositories: 
     39  - 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. 
     40  - 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 
     41    must do some configuring in order to use these library files, see below). We use a tool called [[|ivy]], used by our build files, for easy version management of lib files that relies on our web repositories (, 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”. 
     42  - 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. 
     43  - 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. 
    1247== Starting point ==