The slingc compiler, itself fully implemented in Sling, can compile and translate Sling programs to multiple programming languages, and can be used to turn Sling source code to executable programs.

Filed under

The Eqela Sling Compiler (slingc) can compile (or translate) Sling source code to other programming languages and to executable files. The compiler is normally used through the Eqela Runtime, and does not need to be separately downloaded or installed. To execute a particular version of the compiler, use a command like the following:

eqela eqela:slingc:r325 -help

This should show you the usage. The Eqela Runtime takes care of downloading and caching any necessary files locally. The sample command above would execute the slingc compiler version r325 in particular. Should you need to use any other version of the compiler, simply modify the version number in your command accordingly.

Common usage

While normally used through QX scripts and often through slingbuild, slingc can also be used directly. Obviously the slingbuild scripts and other QX scripts would also ultimately call slingc to compile sling programs. Common usage for slingc would be as follows:

eqela eqela:slingc:r325 -target=<target-platform> my-program-directory-or-file

For example, to compile your code to HTML5 for it to run in a web browser, you could do as follows:

eqela eqela:slingc:r325 -target=html5

For practical samples, also see the Sling tutorial

By default, the output of the compilation will be placed in a subdirectory named "build". If you wish for the resulting files to be saved in some other location, simply use the -output command line parameter:

eqela eqela:slingc:r325 -target=html5 -output=outputdirectoryname

When you run the slingc command with the -help switch, you will see a list of available target platforms. While slingc supports a very wide range of target platforms (even beyond those that are listed), take note that the platform implementation in Jkop may vary, and some platforms are more mature than others.

If you encounter problems or just simply wish to learn more about what happens during a build, you can enable debugging output using the -debug switch:

eqela eqela:slingc:r325 -target=html5 -debug

You will then see much more information while the build is ongoing.

Defining preprocessor variables

The slingc compiler allows the caller to specify values to preprocessor variables that will be substituted in Sling code. This is done by using the -D command line parameter:


For example, if you have this kind of a program:


	PRINT VALUE "myVariable"

And you compile it this way:

eqela eqela:slingc:r325 -target=netcore -DmyVariable=Superman

Then, once executed, the program will print the string "Superman". See also:

Sling: Print statement

Sling: Preprocessor statements

Specifying the source code

The slingc compiler allows you to supply either a file or a directory as the source reference. If a file is supplied, like in the previous examples, it will be compiled directly as Sling source code. If a directory is supplied, however, it is expected to be a Sling module, containing several Sling source code files and possibly a Sling project file. Multiple source references (multiple files or multiple directories) are not allowed.

Specifying library paths

A program is usually assembled as a compilation of different components from different sources, frequently referred to as libraries. For slingc to know which libraries to get from where, you can specify the -libdir= command line parameter to slingc to add the specified directory to the library search path. The parameter is used as follows:

eqela eqela:slingc:r325 -target=netcore -libdir=/home/myuser/code/mylibrary/src -DmyVariable=Superman myprogram

Once done, the compiler will look for dependent libraries in the specified directory. Multiple -libdir parameters can be supplied on the command line.

Filters and custom filters

During the compilation of a program, slingc commonly transforms the program by using a number of filters to translate the code in desired manner. While the exact composition of those filters depends on a lot of factors that are not user dependent, the user is also given some amount of flexibility to customize: The user can specify custom prefilters and postfilters to be executed before and after normal compilation tasks in order to achieve customized functionality.

The user can specify custom filters by using the -prefilter or -postfilter command line parameter:

eqela eqela:slingc:r325 -target=netcore -DmyVariable=Superman -prefilter=@somefilter -postfilter=@someotherfilter

Multiple instances of both -prefilter and -postfilter may be supplied. The given filters will be executed in the sequence in which they were supplied.

By convention, custom filter names are prefixed with the "@" sign. Available custom filters include:

  • @sympathy for server side applications utilizing the Sympathy framework

  • @openapi30 for generating OpenAPI 3.0 compatible API reference documentation

  • @cape for application utilizing the Jkop Cape framework. NOTE: This filter is used by default unless the compiler option -OnoCape is supplied on the slingc command line.

  • @caveui for GUI applications utilizing the cave.ui framework or the Jkop Widgets. Note that the use of UI Expressions in widget applications requires this filter.

  • @motion for applications utilizing the Jkop Motion framework.

  • @capexDataModelSql for generating SQL code for Sling data models.

  • @removeComments will remove all comments from the generated code.

  • @obfuscate will obfuscate the code by renaming classes and other symbol names. Normally used as a postfilter.

Twitter Facebook LinkedIn Youtube Slideshare Github