CCA Port, Component & Application Build Skeleton Templates “A new script toolkit for generating CCA build skeletons” Torsten Wilde and James Kohl Oak Ridge National Laboratory CCA Forum Quarterly Meeting Knoxville, TN ~ January 2004 Research supported by the Mathematics, Information and Computational Sciences Office, Office of Advanced Scientific Computing Research, U.S. Department of Energy, under contract No. DE-AC05-00OR22725 with UT-Battelle, LLC.

1 What’s this all about? 1Creating your own build environment from scratch is not easy unless you are experienced… 1Very hard/impossible if you are not (most users ? ) 1As the complexity increases (e.g. for rpms), the difficulty level increases as well 1CCA build structure is relatively complicated 1lots of dependencies 1additional tool requirements (e.g. Babel) 1Steep learning curve could scare off potential users 1Build “Templates” (Note: NOT C++ Templates) can help you to generate basic CCA code structure in a well defined way

2 Requirements 1Designing a build system is a trade-of between standardization & user flexibility 1Ports are installed for use in CCA components (include/cca- ports, lib/cca-ports) 1Components are installed for use in an application (cca/components) 1Applications combine port and component implementations into a full executable (cca/applications) 1Goal: High level template configuration should be flexible, e.g. using configure, automake, libtools & rpm technology, but should be automated and hide the complexity

3 Template vs. Build Skeleton 1The template files are installed once on your system 1There are generic templates for ports, components or applications 1The build skeleton is created automatically from the templates 1The user edits ONE template configuration file and uses a perl script to generate the specific project skeleton from the generic template files (including subdirectories)

4 Outline 1Two parts: 1How to create/use the skeleton 1Behind the scenes

5 Example: Application Skeleton 1Task: Create an application that uses an existing component and an internal driver (driver lives in the application directory) 1Requirements: 1The component and the port used by the driver are already installed on the system 1The application template is installed 1Example will show and explain the steps involved in the creation and use of the build skeleton 1(similar but less complicated procedures are used for the port and component build skeletons)

6 Creation Process 110 step process 11. User goes into project directory 12. User executes: 1create-cca-application --init 1This will generate the “template-config” file and a usage documentation file in the current directory 13. User edits the template-config file 14. User executes: 1create-cca-application --all 1This will generate the application build skeleton 15. User copies SIDL file for the driver into the driversubdir/sidl/ 16. User executes: 1./run_babel.sh 1This script enters all subdirs and executes a script that generates the source files from the SIDL file using the Babel compiler

7 Creation Process continues 17. User edits the Babel _impl files 18. User edits.in files 1Including info.in, framework files (run_cmdline.in, rc.in files) 19. User executes: 1./autogen.sh 1This will call autoconf, automake & libtools on all configure.ac and Makefile.am in the current source tree 1At the end it will call the top level configure 1Any provided -- options are passed on to it 110. Then, user can call: 1Make 1Make install 1Make uninstall 1Make rpm 1Make backup

8 Outline 1Templates vs. Build Skeleton 1Two parts: 1How to create/use the skeleton 1Behind the scenes

9 Step 2,3 & 4 in more detail 1“create-cca-application –help” shows all available options 1--init 1Creates initialization files in the current directory 1--all 1Builds templates for all packages defined in “template-config” file 1--main 1Builds only the main package templates 1--package=PACKAGE_NAME 1Builds only the specific package template 1--packageexclude=PACKAGE_NAME 1Excludes the specified package from the build tree 1--packagedelete=PACKAGE_NAME 1Deletes the specified package from the build & the directory tree

10 Step 2,3 & 4 in more detail 1The “README_ TEMPLATE” file 1provides step-by-step description of the skeleton creation & usage process 1The “template-config.tempin” file 1This file is the template configuration file 1Packages are defined between [package_name] [/package_name] blocks 1Package [MAIN] [/MAIN] is the only required package name 1Additional packages can be added or delete by the user 1Any change to this file requires re-execution of “create-cca-application”

11 Template-config.tempin in detail 1[MAIN] # The name of your application (also autoconf package name) XXX_MY_NAME_XXX = app-Test-getSumPort # package version XXX_VERSION_XXX = 0.1 XXX_CONTACT_ _XXX = # RPM info XXX_RPM_SUMMARY_XXX = “bla bla." XXX_RPM_DESCRIPTION_XXX = “bla bla" XXX_PACKAGELICENSE_XXX = LGPL XXX_RPM_GROUP_XXX = Development XXX_RPM_REQUIRES_XXX = # component type XXX_CCA_COMPONENT_TYPE_XXX = babel # additional autoconf macros (list separated by spaces) XXX_ADD_AUTOCONF_MACROS_XXX = 1[/MAIN]

12 continue 1# your component name (will be name of subdir as well) [Apps-Driver] # Name of your sidl file including subdirs XXX_SIDL_FILE_NAME_XXX = sidl/driver.sidl XXX_SIDL_IMPLEMENTATION_CLASS_NAME_XXX = Drivers.Driver XXX_SIDL_SERVER_TYPE_XXX = C++ # additional linker flags XXX_ADD_LINK_FLAGS_XXX = # additional compiler flags XXX_ADD_COMPILER_FLAGS_XXX = # list one client port library for each port used and provided # installed client port libs are usually in: usr/local/lib/cca- ports XXX_CLIENT_PORTS_LIB_XXX = -lgetSumPort-client-Cxx # additional needed user library directories & user libraries # add -l in front of each library and -L for each library directory XXX_ADD_LIB_DIRS_XXX = XXX_ADD_LIBS_XXX = # additional needed user header directories # add -I in front of each directory XXX_ADD_HEADER_DIRS_XXX = [/Apps-Driver]

13 Step 6 “run_babel.sh” in more detail 1Script that goes into subdirs and will call “create-client- interface.sh” if there 1Usage : “./run_babel.sh” [OPTION] [OPTION ARGUMENT]... 1Options: 1-[h] or -[-help] Print out command line help. 1-[sbcd] [CCA Spec Babel Config Dir] Points to the directory where the cca-spec-babel-config file is installed. (e.g. -sbcd /usr/local/bin) 1-[bd] [BABEL EXECUTABLE DIR] Points to the directory where the babel executable is installed. (e.g. -bd /usr/local/bin)

14 Step 8 “autogen.sh” in more details 1Script file that will call automake, autoheader and autoconf on all files recursively (if needed) 1Usage: “./autogen.sh” [OPTION] [OPTION ARGUMENT] [ARGUMENTS] … 1Options: 1-[h] or -[-help] Print out command line help. 1-[acmd] [autoconf macro directory] Points to the directory where the standard skeleton autoconf macros are installed. (e.g. -acmd /usr/local/cca/components/autoconf-macros-dir) 1[ARGUMENTS] whatever you would like to let autogen.sh call all configure with at the end (e.g. –prefix=MY_INST_DIR –with-babel=BABEL_DIR)

15 What happens if you change stuff? 1User can edit all build system files by hand after skeleton was created if he needs to (no re-run of the create-cca-xxx command is required) 1If the user changes/deletes or adds entries in the template- config.tempin file, create-cca-xxx has to be re-run 1User can specify the desired behavior with command line options 1Using --package, --all or --main will overwrite only required files (it will make a backup of each file that was changed by the user) 1Using --force in addition will make no backups 1Using --cleanup before rebuilding will erase subsequent build information, after that all files are rebuild

16 Conclusion 1Relative easy to use (provided you use standard install locations) 1only one file to edit 13 commands to call 1Hides build system complexity from the normal user 1Can specify additional configure macros and can use their variables inside the template-config file 1Can specify specific compile/link options inside the template-config file 1Leaves all flexibility in (for advanced users) 1If needed, configure.ac & Makefile.am can be edited directly (changes will be preserved using backup before overwriting) 1Should make the transition to developing for CCA much easier by saving the time and effort needed to create a CCA compatible build environment

17 Future Work 1Probably more to do then apparent 1Enable multiple autoconf macro directories 1Cleanup standard compile/link flags 1Streamline and improve documentation 1Just finished test process last Friday 1Testers/CCA Developers needed to test design and get feedback 1Maybe additional variables or other structuring is needed 1Maybe converting shell script files to perl scripts 1Making skeletons a more generic build tool? 1could be done by taking out CCA specific configure macros and prefixes & putting them into a internal specification file 1For babel or classic mode 1Demo will now follow