1. gLite build and integration system Building and Packaging Robert HARAKALY robert.harakaly@cern.ch

2. , - 2 Contents Build system  Overview  Default targets Non JAVA modules Packaging  RPM  MSI

3. , - 3 Build system overview Ant based framework Designed to support multiple build systems (Ant, make, autotools, etc.) Extensible via the targets-xxx.xml interface mechanism Three layer structure: system, subsystem, component. Additional special build modules can be created to produce deployment units, ex.: org.glite.filecatalog packaging unit.

4. , - 4 Default targets envcheck init checkstyle compile unittestcompile unittest stage doc dist clean install JAVA autotools perl Normally no change Custom target can be added Compile -> all Unittest -> check Stage -> install with prefix Init -> perl Makefile.pl Compile -> all localinit localcompile localclean Local / global targets

5. , - 5 Quality Assurance Integration team enforces and makes audit of the software quality Coding guidelines, documentation, unit tests, etc.

6. , - 6 Non-JAVA modules Full support for non-JAVA modules based on Autotools, make, … Completely transparent for the module developer. Full autotools/make functionality. Default targets are defined in the targets-make.xml (targets- perl.xml) file which must be imported into component’s build.xml file. egee-ant-ext package  Automatically downloaded into the repository.  Provides additional Ant tasks for building non-JAVA (C/C++, Perl, make, autotools, etc.) projects but also packaging tasks.  Provides cross-platform functionality (Win, Linux).  Allows direct use of the predefined Ant properties for C/C++ modules.

7. , - 7 Customization of autotools based modules Customization is done by defining build properties in the project/properties.xml file :  build.{command}.arguments : command line arguments  build.{command}.path : path to find a command  build.{command}.dir : working directory Where command is one of : “bootstrap”, “configure” or “make”

8. , - 8 Sample project/properties.xml file I. <property name=“build.configure.arguments” value=“--prefix=/opt/glite”/> <property name=“build.make.arguments” value=“-d”/> … (other module specific properties) It will result into calls:./bootstrap./configure --prefix=/opt/glite make -d

9. , - 9 <property name=“build.configure.dir” value=“${build.dir}”/> <property name=“build.make.dir” value=“${build.dir}”/> … (other module specific properties) Is equivalent with:./bootstrap cd build../configure make Sample project/properties.xml file II.

10. , - 10 Advanced building In case the existing standard build targets cannot match the developer’s requirements => definition of the “localcompile” target or overloading of the existing standard targets Not a preferred way to proceed Please, do that only after the agreement with the integration team

11. , - 11 Advanced building II. <property name=“build.configure.dir” value=“${build.dir}”/> <property name=“build.configure.arguments” value=“--prefix=/opt/glite”/> <property name=“build.make.dir” value=“${build.dir}”/> <configure dir=“${build.dir}” args=“--prefix=/opt/glite”/>

12. , - 12 Packaging Build system builds source tarballs and binary tarballs and also packages for different platforms:  RPM : RedHat Linux  MSI : MS Windows Packages should be created automatically from the binary tarball files with no or minimum additional information from the developer. Unfortunately, there is always need of some additional information which must be provided by developer Global packaging properties:  package.nameneeded only if source package does not use the standard gLite naming notation

13. , - 13 RPM packaging RPM packages requires set of additional information in order to build the package correctly.  build.rpm.spec.summary  build.rpm.spec.description  build.rpm.spec.buildarch (for JAVA modules should be set to “noarch”) Optional properties  build.rpm.spec.{command}.file Where command is: pre, post, preun, postun, …

14. , - 14 Sample project/properties.xml file …(build properties if any) <property name=“build.rpm.spec.summary” value=“Ant extension targets for C/C++ builds”/> <property name=“build.rpm.spec.install.file” value=“rpm/egee-ant-ext.install”/> Will result to egee-ant-ext.spec file: Summary: Ant extension targets for C/C++ builds … %install {content of the rpm/egee-ant-ext.install file}

15. , - 15 MSI packages Ongoing work on this subject Still not clear which tool will be used. Two candidates:  Wise installer for Windows  Wix (Open Source tool) Component will have defined the project/packaging/${component.name}.??? MSI package specification file MSI package customization through a set of build.msi. properties (not defined yet)

16. , - 16 Main issues (we need help) Functionality/quality race due to limited time Slow information propagation, only few developers are subscribed in the mailing lists Lack of good open source C/C++ auditing tool Packaging and configuration need better definition of the gLite services, their deployment, architecture, run-time requirements, …  ? Brainstorming ?  ? Documentation ?

17. , - 17 Summary Detailed documentation can be found on the web page: http://project-eu-egee-middleware-integration.web.cern.ch/egee-ant-ext Contact by e-mail: robert.harakaly@cern.chrobert.harakaly@cern.ch Any suggestions are welcome