X10 offers a rudimentary library mechanism to support separate compilation of code bases. The basic idea behind the library mechanism is to allow the compiler to separately compile library code once to produce artifacts that can be used in the compilation of a separate (X10) application program that uses this library.  The library code is not required to have a class with a main method.

During the compilation of the application program, the X10 sources of the library code need to be available and will be used for type-checking the application code. However, the X10 compiler will not generate code from the library source files; instead the library versions of the generated code and binaries will be used.

The details of the implementation vary between the managed and native compiler, so we discuss each in turn.

To build a library, x10c should be invoked with arguments “-buildx10lib <path1> -o <path2>/<name>.jar”. This will cause the compiler to emit a file <name>.properties  in the directory <path1> . This is a java property file which contains the entry  “X10LIB_SRC_JAR=<path2>/<name>.jar” and an entry for the “X10LIB_TIMESTAMP” property. x10c will generate the <path2>/<name>.jar file (relative to the current directory if <path2> is a relative path name); this file will contain the X10 sources, the generated Java sources and the binary class files for the X10 code in the library. 

If the library needs to use native (C or C++) code (e.g. because the library uses the X10 @Native mechanism to provide some functionality in Java and the Java code uses the JNI mechanism to access some native code), then the programmer must arrange to produce the required binary files (e.g. .so or .a) and make them available in a directory which should be on the class path of applications using the library. x10c does not need to know the location of these binary files when compiling application (X10) code. 

To use this library, the user should compile X10 application code with x10c, and pass “-x10lib <path to property file>” argument. If the library has associated native code, the location of that code should be specified using  “-classpath <dir>”. 

To run the application, use the x10 command with the name of the application class containing the main method, and specify the location of the source jar for the library through a “-classpath” argument. If native libraries need to be linked in, their location should be specified with a “-libpath” argument.

To create a managed x10lib in the current directory:

$ x10c -buildx10lib . <x10 files> -o ./MyLib.jar

To compile against the created x10lib:

$ x10c -x10lib ./MyLib.properties MyApplication.x10

To run the compiled application:

$ x10 -classpath ./MyLib.jar MyApplication

To build a library, x10c++ should be invoked with “-buildx10lib <path> -d <path>/include -o <name>” arguments. Additionally, the user may specify various command line parameters (e.g. “-Lxx” and “-lxx” commands). On successful compilation, the compiler will generate a file <name>.properties in the directory <path>. This file will contain some other properties besides X10LIB_SRC_JAR and X10LIB_TIMESTAMP (described above). For example, the X10 Global Matrix Library properties file for MacOS looks like:

X10LIB_PLATFORM=darwin64
X10LIB_CXX=g++
X10LIB_CXXFLAGS="-DENABLE_BLAS" "-DENABLE_LAPACK"
X10LIB_LDFLAGS=
X10LIB_LDLIBS=-lnative_gml "-L/opt/OpenBLAS/lib" "-lopenblas" "-L/usr/local/lib" "-lgfortran"
X10LIB_SRC_JAR=native_gml.jar

The compiler will generate various *.cc and *.h files in the <path>/include directory, a binary object file lib<name>.so in the <path>/lib directory, and a jar file <path>/<name>.jar containing the X10 source files.

To use this library, the user should compiler the X10 application code with x10c++ and pass “-x10lib <runpath>/<name>.properties” argument. <runpath> may be different from <path>, e.g. because the programmer installed the property file at some location other than the one where it was generated.  However, in this case the programmer must make sure that  the contents of <path>/lib and <path>/include directories are also moved in synchrony. When application code is being compiled, the post-compiler will expect to find the *.cc and *.h files generated during compilation of the library at <runpath>/include, and the binary object file in <runpath>/lib. (The compiler arranges for this by generating "-I<runpath>/include” and “-Wl,<runpath>/lib” arguments for the post-compiler.)

The application executable built by the compiler (e.g. a.out) can be executed directly. Any dynamically linked libraries must be in the library path for execution.

To create a native x10lib in the current directory:

$ x10c++ -buildx10lib . <x10 files> -o MyLib

To compile against the created x10lib:

$ x10c++ -x10lib ./MyLib.properties MyApplication.x10 -o MyApplication.exe

To run the compiled application:

$ ./MyApplication.exe