The versions 1.0, 1.1 had been done by using the Geant4 code tagged geant4-09-05-ref-00.
The detector model is the one of the A01 example which is "in spirit" pretty close of what is done on a fixed target HEP experiment. This model includes a source (positron by default), a "beam line" with a magnet in middle and at end a detector sandwich with hodoscopes, electromagnetic and hadronic calorimeters (some kind of standard HEP "big mac"). We choosed this model also because its visualization is definitely not reduced to "a cube" and anyway rather compact and simple to give a good visual feeling.
The build relies from the file :
g4exa_source-<version>.zip
found on the download area. This file contains "what is needed from Geant4".
The source distribution contains a copy of the needed Geant4 files used by the application. In the copying process, we had stripped various directories and files as the test and benchmarks ones, the gdml one (that needs xerces), the interfaces and visulization ones (we use our own tools) and a couple of other things that posed problems (for example processes/hadronic/models/abla). Mainly we keep only the "Geant4 core".
We do that in order to give "at once" the Geant4 core to Xcode in the case of building for iOS and MacOSX/Cocoa but also give "at once" Geant4 to the Android gmake system if building the Android app "apk" (we don't use Eclipse). For these platforms we prefer to use straight the Apple and Google tools that offer also the tools to pack the app "ready for the stores" (Apple AppStore and GooglePlay). In the case of the AppStore, the building and submission system of an app to Apple from Xcode is already sufficiently painfull (thought at CERN?) to avoid complicating the life by using a third party build tool. Another constraint is that the stores put limits on the size of an app and we can't, in the case of using Geant4, build all the various G4 libs and include them in the pack; it would explode the limits. By declaring the G4 sources to Xcode and Android-gmake, and then avoiding to build in-between libs, we let the linker sort out what is needed in the binary. On Android the apk of the 1.0 is only 4 Mbytes and around 8 Mbytes for the AppStore pack, something rather remarkable in fact.
Another issue is the "data files" needed by some Geant4 processes. Even if zipped, these are clearly too big to be included in the packs. For a "serious app", someone would have to download them from the internet onto the device and arrange so that the app knows the device installation place. For this particular simple app, in order to simplify the installation, we have decided to include in the "resources" of the packs what is needed from these data files to run the physics of "A01 shooting positrons". A little "g4emlow_[version].zip" (150 Kbytes) comes with the packs. At startup it is unfolded into the "temporary directory" of the app and a "putenv G4LEDATA" is done dynamically to point to the right directory.
You can build the X11 version of the app by first building a "libgeant4.a" with :
UNIX> cd g4exa/inexlib/ourex/geant4
UNIX> ./build -compile # it creates ./build_dir_gcc directory
UNIX> ./build -archive # it creates ./build_dir_gcc/libgeant4.a
On MacOSX you can use the clang compiler (much faster than g++!) :
Darwin> ./build -compile -clang # it creates ./build_dir_clang directory
Darwin> ./build -archive -clang # it creates ./build_dir_clang/libgeant4.a
As explained, in order to get a compact binary we don't seek to build shared libs, we concentrate on an archive library in order to have "all in the binary" and then simplify the packing and distribution of the app. Note that the build shell script does not use gmake! It simply does a UNIX "find .cc", loops on found .cc files and compiles them. We arranged to keep this script simple so that tweeking it should be rather straightforward. In case a compilation fails on some file, you can restart from the "problematic category" by editing what goes in the "g4_dirs" variable.
Must be pointed out also that the fact that now "what is needed of CLHEP" comes with the Geant4 sources, definitely eases the overall task.
When having a libgeant4.a, you can build g4exa for X11 with :
UNIX> cd g4exa/g4exa/X11
UNIX> ./build
(Darwin> ./build -clang)
When done, you should have a distrib directory with the X11 packing :
g4exa-<version>-<platform>.zip
but you can run with :
UNIX> ./distrib/g4exa/<version>/bin/g4exa
As explained, at startup, the program unfolds the data file :
./distrib/g4exa/<version>/res/g4emlow_<version>.zip
into the temporary directory :
/tmp/g4exa_<pid>_<number>
This directory should be deleted when exiting properly the program.
The Windows build does not use the Visual IDE nor .bat files. We proceed by executing the g4exa/X11/build bash shell script from CYGWIN. The script detects that you are under CYGWIN and uses the cl.exe compiler and link.exe linker of a Microsoft Visual Studio installation to build the binary. Then g++ is not used, and it is truely win32 (and not X11) and the Microsoft OpenGL which are used for the windowing and graphics. In fact we use CYGWIN only for the bash shell! (and zip.exe).
The overall procedure is :
Install a Visual Studio (we had used a Visual 9).
Install what is needed from CYGWIN to get a bash shell, zip.exe, unzip.exe.
Create a DOS terminal with :
Start -> Programs -> Accessories -> Command prompt
Setup Visual (before launching CYGWIN) with something as :
DOS> "C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools"\vsvars32.bat
Launch CYGWIN, probably with :
DOS> cd C:\CYGWIN
DOS> call cygwin.bat
If not done, from the CYGWIN prompt, get and unzip the g4exa_source zip file.
From the CYGWIN prompt, you should be able to do :
CYGWIN> cl.exe
CYGWIN> lib.exe
After, the build proceed as for X11 :
CYGWIN> cd g4exa/inexlib/ourex/geant4
CYGWIN> ./build -compile # it creates ./build_dir_cl_exe directory
CYGWIN> ./build -archive # it creates ./build_dir_cl_exe/libgeant4.a
When having a libgeant4.a, you can build g4exa for Windows with :
CYGWIN> cd g4exa/g4exa/X11 # and not from g4exa/g4exa/win32 !
CYGWIN> ./build
When done, you should have a distrib directory with the Windows packing :
../win32/distrib/g4exa-<version>-<platform>.zip
but you can run with :
CYGWIN> cd ../win32
CYGWIN> ./distrib/g4exa/<version>/bin/g4exa
As the program does not use any env variables, you should be able to run it straight from a DOS prompt :
<create a DOS terminal>
DOS> cd C:\cygwin\home\<user>\g4exa\g4exa\win32
DOS> .\distrib\g4exa\<version>\bin\g4exa.exe
or even by clicking on the g4exa.exe from the file browser.
As explained, at startup, the program unfolds the data file :
./distrib/g4exa/<version>/res/g4emlow_<version>.zip
into the temporary directory. On a Windows the temporary directory is done by using the env variables TEMP.
You have to open Xcode on :
g4exa/g4exa/Cocoa/g4exa.xcodeproj
For example from a terminal :
Darwin> open g4exa/g4exa/Cocoa/g4exa.xcodeproj
and then select the Debug or Release "configuration or scheme" and do a "Build". We do not explain how to do that here since things had changed a lot between a Xcode-3 and a Xcode-4. (We have used a Xcode-4 on a Lion MacBookPro). We assume that if you attempt to do a Xcode build you know a little bit about this tool...
Note that, contrary to the UNIX/X11 build, you don't have to build a libgeant4.a before activating Xcode/Build. The paths toward the directories :
g4exa/inexlib/ourex/geant4/source
g4exa/inexlib/ourex/geant4/include/Geant4
are declared in the g4exa.xcodeproj/project.pbxproj along all the Geant4 core .cc files! When starting the build, Xcode passes a lot of time in "indexing" things, and the build itself being definitely lengthy (even if using clang), then it would be a good time for... coffee!
In case of problem, do not hesitate to tweek by hand the :
g4exa/g4exa/Cocoa/g4exa.xcodeproj/project.pbxproj
(ok, ok, we should not say that but well...)
You have to open Xcode on :
g4exa/g4exa/iPhone/g4exa.xcodeproj
Instructions are rather similar than for the upper Cocoa build section but in case of building for a connected device, you will have to fight with the messy Apple certificate and provisionning system...
If wanting to build a new app with your own simulation in order to "publish" on the AppStore, you will have obviously to rename "g4exa" to a name of your own. You have to know that Xcode permits that, but as the procedure had changed from Xcode-3 to Xcode-4, we let you find the right way to proceed in the adequate Xcode documentation. Here we definitely don't want to speak about how to publish this new app on the AppStore...
To do that you need first to install a "SDK" and a "NDK". We have used a MacBookPro under Lion with the kits :
android-sdk_r16-macosx
android-ndk-r7
As G4 uses a lot the STL, you will need a NDK having a STL and the ndk-r7 has that, but it compells to distribute on devices from Android-2.2. (For the story we had upgraded our SGS-1 from Android-2.1 to 2.2 by using KIES on a Windows. It did not worked with KIES on Mac). When done, go in :
g4exa/g4exa/Android/mgr
and edit the setup_r7.csh or setup_r7.sh to tell where you have installed your SDK and NDK. Then :
csh> source ./setup_r7.csh
or :
sh> . ./setup_r7.sh
Before doing a ./build from here, you have to change the "key" used to sign the .apk. You do that with :
UNIX> cd ..
UNIX> ./genkey
You will be asked to give a password that will be required when building the .apk. The ./genkey should produce a new g4exa.jks file. When done, you are ready to build :
UNIX> cd ./mgr
(UNIX> chmod a+x ./build)
UNIX> ./build # and take a coffee.
If successful and if a device is connected, the build script will do a :
UNIX> adb install -r ../bin/g4exa-release.apk
to upload the apk on your device (no need of a fancy certificate and provisionning system here). At startup, the g4emlow_[version].zip will be unfolded under the directory :
/data/data/fr.in2p3.lal.g4exa/files
The paths toward :
g4exa/inexlib/ourex/geant4/source
g4exa/inexlib/ourex/geant4/include/Geant4
are enforced in the file :
g4exa/g4exa/Android/jni/geant4.mk
included from :
g4exa/g4exa/Android/jni/Android.mk
As for the Cocoa and iOS build, you don't have to prebuild a libgeant4.a, for what concerns Geant4 all is said in the geant4.mk.
As for iOS, if wanting to build a new app with your own simulation in order to publish on GooglePlay (ex AndroidMarket), you will have obviously to rename "g4exa" to a name of your own. Today we don't have a straightforward procedure to to that, you will have to do things by hand (but there is not so much to do). The positive point is that depositing an app on GooglePlay is much more simple (and cheaper!) than for the AppleStore (no need of a CERN salary for that).
If you want to use another Geant4 core code than the one coming with our "ourex" distribution, the copy of "what is needed from G4" is done by the "build" bash shell script found at :
g4exa/inexlib/ourex/geant4/build
The build script is activated with :
UNIX> cd g4exa/inexlib/ourex/geant4
(UNIX> chmod a+x ./build)
UNIX> <in "build", edit g4_home to tell where are the Geant4 sources>
UNIX> ./build -cp_incs # it creates a ./include directory
UNIX> ./build -cp_ccs # it creates a ./source directory
In order to share the same "inexlib/ourex/expat" as the inlib/exlib tools, and avoid messy situations with existing expat found on the platform, you have to change by hand in :
g4exa/inexlib/ourex/geant4/include/Geant4/xData.h
the line :
#include <expath.h>
with the line :
#include <ourex_expath.h>
In ourex/expat/include/ourex_rename.h, by using cpp macros, we do a change of namespace which guarantees to use a consistent set of .h/.c for expat.