Skip to content

Build System

Jump to bottom Edit New page
Andrei Pozolotin edited this page Jan 3, 2013 · 8 revisions

Introduction

This project has 3 build systems:

  • Release NAR
  • Staging NAR
  • Testing CDT

each build system will produce artifacts with specific names and at specific locations which are both arch and os dependent;

barchart-udt native library loader will use the following search priority when looking for these artifacts:

  • Release NAR
  • Staging NAR
  • Testing CDT

Pre-Requisits

Ubuntu 10.04

use 64 bit os;

use [multi-libs] (https://help.ubuntu.com/community/InstallingCompilers);

sudo apt-get install gcc build-essential libc6-dev ia32-libs g++-multilib  libc6-dev-i386

MacOSX 10.6.5

use 64 bit os;

use xcode;

use java developer package;

Windows 7

use 64 bit os;

use tdm-gcc with install in c:\mingw32 & c:\mingw64;

use [launch script] (https://github.com/barchart/barchart-udt/blob/master/barchart-udt-core/build/jenkins/slave-job-windows-gpp.cmd) to set PATH for mingw32 or mingw64 before invocation of eclipse ;

JDK 1.6

install both 32 and 64 bit java in separate folders;

do not include either java on the path;

macosx java comes as "bundle"; regardles of what (32/64 java) is active on your system by default you must explicitly provide -d32 / -d64 for all java invocations for this project;

Eclipse 3.7

use [eclipse pulse] (http://www.poweredbypulse.com/)

ask for current barchart-udt eclipse-pulse profile to be shared for you;

setup both 32 and 64 bit jre in your eclipse under the names "java32" and "java64"; macosx needs -d32 or -d64 options;

eclipse itself must run on top of JDK, not JRE;

Tutorials

intro for CDT

intro for JNI

Testing CDT

used for interactive development of both java and c++ code inside eclipse; allows to handle only single target os at a time; allows to test both 32/64 bits builds on the same os;

you must have eclipse CDT installed in your eclipse before you will be able to see CDT project configuration settings;

you must also activate [eclipse CDT perspective] (http://www.ibm.com/developerworks/opensource/library/os-eclipse-stlcdt/fig08.jpg) ;

you must select your matching [build configuration] (http://wiki.eclipse.org/images/f/ff/New_cdtwsconfig_wsContextMenu.png)

Project -> Build Configurations -> Set Active -> cdt_{arch}-{os}-gpp

there are 6 CDT configs in this project (for each arch and os):

  • cdt_i386-Linux-gpp
  • cdt_amd64-Linux-gpp
  • cdt_i386-MacOSX-gpp
  • cdt_x86_64-MacOSX-gpp
  • cdt_x86-Windows-gpp
  • cdt_amd64-Windows-gpp

when CDT makes a build, you will see that a resource folder appears in you project with the same name as configuraton name; if you want CDT to re-build given configuration w/o "project clean" - just delete the resource folder; this folder is not part of source repository;

you must select active build configuration that matches your platform arch and current java bitness (32 vs 64);

you must have 2 named java jre defined in your eclipse: "java32" and "java64" (on macosx you must provide -d32/-d64 options to your java)

you must map one of these java jre to the "java se 1.6" in your eclipse;

every time you update/save your java / c++ code in eclipse the following will happen:

  • java will get compiled and placed in target/classes
  • c++ will get compiled and placed in cdt-{arch}-{os}-gpp folder as well as into target/test-classes
  • console will show c++ build errors, if any;
  • double-click on the highlighted c++ console error will bring you back to the c++ source at the location of the error;

to dispel the black magic of CDT build, take a look here:

Project -> Properties -> Builders

you will see that when eclipse detects change, the following steps are performed:

  • Java Builder, provided by JDT, runs incremental javac
  • Eclipse_JNI_Build, provided by this project, runs incremental javah
  • CDT Builder, provided by CDT, runs incremental gcc
  • Eclipse_LIB_Copy, provided by this project, runs artifact copy
  • Scanner Configuration Builder, provided by CDT, runs cdt parsers
  • Maven Project Builder, provided by M2E, copies extra resources as defined in pom.xml

location of produced "Testing CDT" native libs (example):

${project}/target/test-classes/libbarchart-udt-core-i386-Linux-gpp.so

Staging NAR

used for verification that maven-nar-plugin settings match to CDT settings; and that both CDT and NAR produce identical libraries/artifacts - while still in IDE;

[current nar settings] (https://github.com/barchart/barchart-udt/blob/master/barchart-udt-core/aol.properties)

there are numerous "maven launch configurations" provided for various maven-related tasks, in form of nat scripts, with names such as maven-package.ant study them and create your own;

for example:

location of "Staging NAR" native libs (example):

${project}/target/test-classes/barchart-udt-core-X.Y.Z-SNAPSHOT-i386-Linux-gpp-jni/lib/i386-Linux-gpp/jni/libbarchart-udt-core-X.Y.Z-SNAPSHOT.so

Release NAR

used for multi-arch-os jenkins auto build with maven-nar-plugin;

the process involves brining up all target platforms (jenkins slaves in vm), building libraries, running unit tests, running integration tests, uploading jars and nars to the release/snapshot repo, etc;

location of "Release NAR" native libs inside final jar (example):

/lib/i386-Linux-gpp/jni/libbarchart-udt-core-X.Y.Z-SNAPSHOT.so
Add a custom footer
Add a custom sidebar
Clone this wiki locally