Compiling Concurnas code?
Table of Contents
Concurnas code can be compiled is via the
concc command line tool or via IDE which has support for Concurnas. Here we shall examine the
concc command line tool. We can compile a
.conc file as follows:
concc command line tool has the following syntax:
concc options sourcefiles/directories
There must be at least one sourcefile or directory provided as an argument. Source code files must have the
.conc suffix to be compilable. If a directory reference is provided then this will be searched, including nested directories, for
.conc files. Multiple entries can be delimited with a space.
.conc file has a dependency on a
.conc file listed in the same directory, then the dependant
.conc file will also be compiled.
By default the
.conc files will be compiled in to one or more .class file per source file input, into the same directory as the original sourcefile. To override the output directory of the .class files, use the -d option described below. Where the output directory has been overridden, if it does not already exist, Concurnas will attempt to create it.
The directory hierarchy relative to the working directory of the
concc call denotes the package name of the output .class files for
.conc files specified in the sourcefiles. The root directory is the current working directory in which
concc is run. The root working directory can be overridden using the -root option described below. All referenced source files are taken to be relative to this directory.
Where a directory is specified for compilation, the root of the directory is taken to be root for nested
.conc files for the purposes of package name generation. The exception being where the specified directory path is fully qualified, in which case the base of the nested hierarchy will be taken as the root directory for package name generation purposes.
Sourcefiles and directories may also be prefixed with an element specific root directory. This will override the global root directory (if specified) or default working directory. The syntax for this is as follows:
root[sourcefiles or directories]
Using an element specific root is generally the easiest method by which one can perform compilation with correct package names for multiple source files existing across multiple directories.
There can be zero to many options specified on a call to
-d directory: Override the directory where .class files will be output. concc will try to create this directory if it does not already exist.
-a or -all: Copy all non .conc files from source directories to provided output directory (output directory is overridden with the -d option).
-jar jarName[entryPoint]?: Creates a jar file from all generated/copied files. Optional entryPoint class name may be specified which will be used to populate a META-INF/MANIFEST.MF file within the jar. Can only be used in conjunction with the -d option.
-c or -clean. Remove all generated files from output directory. Useful in conjunction with -jar option. Any generated jar files will not be removed.
-classpath path or -cp path: The classpath option enables one to override the CLASSPATH environment variable. Elements are delimited via
;and must be surrounded by
""under Unix based operating systems. Elements may consist of directories,
.classfile references or
-verbose: Provide additional compilation information including bytecode output.
-root directory: Override the root directory of
javacc. Package names for
.concfiles will be generated relative to this.
-werror: Normally, warnings do not prevent class file generation, setting this tag will treat warnings as errors, thus preventing class file generation warnings are generated for the input
.concsource file in question.
-J: JVM argument. Prefix jvm arguments with -J in order to pass them to the underlying JVM. e.g.
-D: System property. Prefix system properties with -D in order to pass them to the underlying JVM. e.g.
--help: List documentation for options above.
It is recommended that the -d directory option be used for all but the most trivial of compilations.
Compile all code in
.src relative to default working directory:
Compile all code in
.src relative to default working directory but override the output directory, writing output classes to
concc -d ./classes ./src
As par previous example and (via
-a option) copying all non .conc files to
concc -a -d ./release ./src
As par previous example but additionally packaging all files in output directory into a jar:
release.jar and removing all copied files from the output directory except the output jar,
concc -a -clean -jar release.jar -d ./release ./src
As par previous example but additionally specifying an entry point (
com.mycompany.product.Start) the main method of which will be executed in the event of execution via the
concc -a -clean -jar release.jar[com.mycompany.product.Start] -d ./release ./src
Compile all code in
.src relative to default working directory and
concc ./src ./extrasrc/Mycode.conc
As above but override the root of
Mycode.conc to be
extrasrc (thus the package name of the code in
Mycode.conc will not be prefixed with
concc ./src ./extrasrc [Mycode.conc]
As above but override the output directory, writing output classes to
concc -d ./classes ./src ./extrasrc [Mycode.conc]
As above but with custom libraries (jars and classes) set on the classpath:
concc -cp ./include/MyLib.jar;./include/UtilClass.class -d ./classes ./src ./extrasrc [Mycode.conc]
Arguments (for example garbage collection and memory allocation tuning) may be applied to the underlying JVM executing
concc by prefixing them with
-J. For example:
concc -J-Xmx2g ./src ./extrasrc/Mycode.conc
System properties may be specified on the command line when running
concc by prefixing them with
-D. For example:
concc -Dcom.mycompany.mysetting=108 ./src ./extrasrc/Mycode.conc
Adding concc to the path?
It is recommended that the
<installDir>/bin be added to the system path in order to permit
concc to be run from any path. Check your operating system documentation for details of how to do this. The Windows installer for Concurnas will perform this automatically, as will installation via the SDKMAN! platform.
Jar's are an excellent way of packaging code for organization and distribution. As seen above the
concc tool is able to create these as described previously. Additionally the jar tool provided as part of the JDK can be used to achieve this objective.
The first time the
concc tool is executed, or when a new JVM environment upon which is its being executed is detected, an 'installation' will take place wherein Concurnas will set itself up to execute efficiently upon said JVM environment by caching a copy of the JDK. This can take up to a few minutes to complete.