Reference

Usage

Tecmake usage is quite simple. Just call "tecmake" in the folder that contains the "config.mak" file. If your configuration file has a different name, then you should call:

tecmake MF=myconf

In Windows, to add any parameter you must first add the platform, i.e. "tecmake rebuild" must be "tecmake vc7 rebuild" even if vc7 is the default platform. Also in Windows to add a definition you must enclose it with quotes, for ex:

tecmake vc7 "MF=myconf"

Parameters

MF=<file>
Name of the user's configuration file. Default name is "config". The extension ".mak" will be added. Must be present in the folder "src". A distribution file name will also be used, "config.dist" as default.
build (default target)
Compiles to the current platform. It is the target executed when no target is passed in the command line. In this order: it creates the required folders, compiles, generates links to exported files, and generates scripts/batches for applications in order to run them without the need to change the current folder.
In UNIX it also generates a script to call the depurator with the application executable as parameter. One can edit the scripts or create "app.env" or "debug.env" files to be loaded by the respective scripts.
<platform>
Compiles to the specified platform. In UNIX it is the system's TEC_UNAME. In Windows it is the compiler's TEC_UNAME - in this case, the use of this parameter is required for other parameters to work.
In UNIX each compilation starts in a different xterm - therefore, to use this option, one needs to be at a X11 client. The windows are viewed with black background and LightBlue letters, with the name of the respective library displayed in the title. In Windows the platforms will be executed one at a time and it does not include the generation of DLLs (for such, use "all-dll").
depend
Builds the list of dependencies among source files (.c and .cpp) and inclusion files (.h). If the gcc compiler is not installed, tecmake will not be able to execute this option, informing this to the user. The list is stored in a file with the name specified in APPNAME or LIBNAME with extension ".dep". It is dependent on the file config.mak - therefore, every time the latter is changed, the former will be updated.
clean-dir
Deletes all generated folders and their contents.
clean-lohs
Deletes all generated Lua object files.
clean-obj
Deletes all object files generated in the given platform.
clean-all-obj
Deletes all object files generated in all platforms.
clean-target
Deletes the library or executable generated in the given platform.
clean-all-target
Deletes the library or executable generated (in all platforms).
clean
Deletes the object files, library or executable generated in the given platform.
clean-all
Deletes everything the makefile generates: the contents of folders obj, lib, inc and lua, temporary files, and files that are not locked by RCS (ir RCS is activated).
rebuild
Deletes all generated files and recompiles only for the given platform.
relink
Deletes generated files except object files and recompiles only for the given platform.

version
Informs the current version of tecmake.

Variables

In the configuration file the user defines, by means of variables, parameters to be used by tecmake. All variables accepted are described below. The syntax to define a variable is VAR = VAL1 [VAL2...]. Variables can also be specified in the command line, for instance:  tecmake MF=test.

Most variables are optional, some of them have default values and a few of them are required.

Project Names

PROJNAME
Name of the project that contains the library. A single project can contain more than one library or application.
default: the value of variable LIBNAME or APPNAME
APPNAME
Name of the application to be generated. Mutually exclusive with LIBNAME.
Required.
LIBNAME
Name of the library to be generated. Mutually exclusive with APPNAME.
Required.
Libraries will be called:
    $(LIBNAME).lib and $(LIBNAME).dll in Windows
    lib$(LIBNAME).a and lib$(LIBNAME).so in UNIX
    lib$(LIBNAME).a in Windows when using gcc for static libraries
    $(LIBNAME).a and $(LIBNAME).dll in Windows when using gcc to build a DLL and its import library
    lib$(LIBNAME).dll.a and cyg$(LIBNAME).dll in Windows when using gcc and Posix to build a DLL and its import library

Files and Folders

SRC
Source files in C (extension .c), C++ (extension .cpp) and FORTRAN (extension .f or .for). Source-code files must not contain absolute paths, but they can be located in subfolders. Folder separation must be indicated using the character "/", even in Windows. File names can not be distinguished only by their extensions.
Required.
SRCLUA
Source files in Lua that must be compiled to LO and LOH, or to LH. Since this is made only once for all platforms, they are specified separately. The command line programs "bin2c*" and "luac*" must be in path. "The binary files created by luac are portable only among architectures with the same word size and byte order." See Lua Files as Binary for more details.
SRCDIR
Base folder of the library or application, if different from the current (src). Useful when the files are in a subfolder, because otherwise it would be necessary to add the folder name as prefix to all source files.
SRCLUADIR
Base folder for Lua files, equals SRCDIR when not defined.
LOHDIR
Base folder for ".loh" files, equals SRCLUADIR when not defined.
USE_LOH_SUBDIR
Creates a subfolder in LOHDIR (one for each platform) and add it to the INCLUDES definition.
LOHPACK
Allow generating a single LOH file that will pre-load all the Lua modules of the application
LHDIR
Base folder for ".lh" files, equals SRCLUADIR when not defined.
USE_LH_SUBDIR
Adds the LHDIR to the INCLUDES definition.
NO_LUAOBJECT
Instead of building LOH files from SRCLUA, it will build LH files.
EXTRADIR
Extra directories to be created before build.
INCLUDES
Folders of inclusion files required to compile the library or application. Their definition is typically required (only very simple projects do not require the resources provided by this variable). Prefixes -I must not be present.
EXTRAINCS
Same as INCLUDES, but it is added after the internal standard includes.
LIBS
Names of the libraries on which the application or DLL depend. Must be specified without the lib prefix or the suffixes .a or .so. The prefix -l also must not be added.
LDIR
Folders where the libraries to be used by the linker stage are located. Absolute or relative paths can be specified. Prefixes -L must not be provided.
SLIB
Static libraries that will be linked together with object files. Must be informed with their complete absolute path. The libraries specified in this variable cannot be also present in the LIBS variable. As, in Windows, the default is the use of static libraries, the use of this variable is more common in UNIX applications. In this case, one should also have a conditional defining LIBS for Windows and SLIB for UNIX.
DIR
Additional folders used in distribution (option dist), installation (option inst).
EXTRASRC
Additional source files to be included in the distribution tar. Since the tar is made in UNIX, one should include files from other systems in this variable.
EXTRADEPS
Files from which the library or application depends which were not included in the variables SRC, INC, SRCLUA. tecmake does not have a default rule to generate these files. If they are not present, all that will be done in the generation of the library is an attempt to retrieve them from RCS, if this is the case. However, the user can still define specific rules for such files in the config.mak file.
EXTRA_CONFIG
Allows an extra configuration file to be loaded. It must contains the complete file name of the file to be loaded.
DEPENDDIR
Base folder for dependencies files. This will also change the dependency file name format to "DEPENDDIR/TARGETNAME.dep.TEC_UNAME".
NO_DEPEND  [Yes|Not Defined]
Disables the usage of the dependencies file.
default: not defined.
NO_SCRIPTS [Yes|Not Defined]
Will not build the command line scripts in the current folder.
DEF_FILE (Windows Only)
Specifies the name of the .def file, necessary to generate the dynamic library (DLL). tecmake's default is <LIBNAME>.def.
OBJROOT and TARGETROOT
Root folder where the object and binary files are stored, respectively. These variables can be used to redirect the generated files to the local disk, for instance.
TEC_UNAME_DIR
Secondary folder where the object and binary files are stored. This folder is created inside the OBJROOT and TARGETROOT folders.
TEC_UNAME_LIB_DIR
Secondary folder where the Tecgraf libraries files are stored. For ex: "$(IUP)/lib/$(TEC_UNAME_LIB_DIR)".
LUA_INC, LUA_LIB and LUA_BIN
Used to overwrite the default Lua includes, libraries and executables folders.
IUP_INC, IUP_LIB, CD_INC, CD_LIB, IM_INC and IM_LIB
Used to overwrite the default location of includes and libraries. For example: instead of $(IUP)/include it will use $(IUP_INC) if defined, or $(IUP)/lib/$(TEC_UNAME) it will use $(IUP_LIB) if defined.

Libraries

USE_IUP3, USE_IUP, USE_IUPLUA, USE_IUPCONTROLS,
USE_IM, USE_IMLUA, USE_CDLUA, USE_CD, USE_GDIPLUS, USE_XRENDER,
USE_LUA, USE_LUA4,
USE_LUA5, USE_LUA50, USE_LUA51, USE_LUA52,
USE_GTK, USE_GDK, USE_CAIRO, USE_MOTIF, USE_X11, USE_OPENGL, USE_GLUT 
[Yes|Not Defined]
If defined, internally change the variables INCLUDES, LIBS and LDIR to include paths and binaries required for compile and linking with the specified library. There are some dependencies:
if USE_STATIC is NOT defined then
            USE_IUP implies USE_MOTIF (in UNIX)
            USE_IUP3 implies USE_MOTIF (in IRIX, AIX and SunOS)
            USE_IUP3 implies USE_GTK (in Linux and BSD) if USE_MOTIF is NOT defined
            USE_CD, USE_GTK, USE_MOTIF and USE_OPENGL implies USE_X11 (in UNIX)
USE_GDK implies USE_GTK
USE_GTK implies USE_GTK3 when in Linux3*
USE_IUPLUA implies only USE_IUP (you must define which Lua you are using with USE_LUA#)
USE_CDLUA implies only USE_CD, USE_IUPLUA implies only USE_IUP
default: not defined.
USE_IUPBETA, USE_CDBETA, USEIMBETA [Yes|Not Defined]
Adds the folder "/beta" to the library base path.
USE_STATIC [Yes|Not Defined] (UNIX Only)
Forces the use of the static versions of the libraries above.
NO_LUALINK [Yes|Not Defined]
USE_LUA will only add the include folder for the compiler but will NOT add the library for linking in UNIX.
USE_DLL [Yes|Not Defined] (Windows Only)
Configures the use of the RTL as a dynamic library.
USE_MT [Yes|Not Defined] (Visual C++ Only)
Configures the use of MSVCRT as static library with multithread support.
USE_ATL [Yes|Not Defined] (Visual C++ Only)
Configures the use of the Microsoft ATL library.
USE_CLR [Yes|Not Defined] (Visual C++ Only)
Configures the use of the Microsoft Common Language Runtime.
USE_OPENMP [Yes|Not Defined] (Visual C++ and Gcc Only)
Enable OpenMP support.
USE_CPP11 [Yes|Not Defined] (G++ Only)
Enable C++ 11 standard support.
USE_NOCYGWIN  [Yes|Not Defined]
Disables the usage of the cygwin DLL when using gcc. The build will be compatible with the MingW compiler and use the "MSVCRT.DLL".
default: not defined.

Tools Flags and Parameters

DEFINES
Definitions available during compilation. Prefixes -D must not be provided. This variable has some predefined values, see Pre-defined Variables.
FLAGS
Additional flags for the C compiler.
CPPFLAGS
Additional flags for the C++ compiler.
FFLAGS (UNIX Only)
Flags for FORTRAN compiler.
LFLAGS
Additional flags for linking applications and dynamic libraries. Not used for static libraries.
LCFLAGS
Additional flags for building static libraries.
DBG [Yes|Not Defined]
If defined, activates the flags to include depuration information. If the variable DBG_DIR is also defined, the suffix "d" is added to the folder where the binaries are generated. If the variable DBG_LIB_DIR is also defined, the suffix "d" is added to the folder where the Tecgraf libraries are installed.
default: not defined.
OPT [Yes|Not Defined]
If defined, activates the flags to compilation with optimization. The optimization is defined by variable OPTFLAGS, whose default value is -O2 for GCC. This definition is ignored if DBG is defined.
default: not defined.
STRIP [Yes|Not Defined] (UNIX Only)
If defined, removes from the application all the symbols for depuration after linking, resulting in a smaller executable.
BUILD_DYLIB [Yes|Not Defined] (MacOSX Only)
If defined, the linker will build dynamic libraries instead of shared code libraries (bundle). Dynamic libraries will have ".dylib" extension, while share code libraries use the common ".so" extension.
BUILD_64 [Yes|Not Defined] (UNIX Only)
If defined, the compiler will receive parameters to generate 64-bit code. Works only in AIX with CC and in machines with GCC 3 prepared to 64 bits. If the variable BUILD_64_DIR is also defined, the folder where the binaries are generated is added the suffix "_64".
NO_DYNAMIC [Yes|Not Defined] (UNIX Only)
If defined, this variable determines that dynamic versions of the libraries must not be generated.
default: not defined, except for AIX that is Yes.
NO_ECHO [Yes|Not Defined]
Disable the echo of commands.
GEN_MANIFEST (Windows Only)
Enable automatic manifest file generation and embedding.
default: not defined , except for DLLs that is Yes.
APPTYPE (Windows Only)
Defines the type of Windows executable, either with interface (windows) or for command line (console).
default: windows

Tools

CC
Compiler to be used with .c files.
default: gcc (UNIX)
FC (UNIX Only)
Compiler to be used with .f and .for files.
default: f77
CPPC
Compiler to be used with .cpp files.
default: g++ (UNIX)
LINKER
Linker to bind the object files and creates an executable. If SRC contains .cpp files then a C++ linker is automatically selected in some configurations. If want that a C++ linker be used independent from SRC contents then use LINKER to specify one.
COMPILER (Windows Only)
Folder where the compiler is located. Can be used to force the compiler's use in local disk.
NO_LOCAL_LD [Yes|Not Defined]
Disable the usage of the "ld" tool as linker in IRIX and SunOS.
USE_CC [Yes|Not Defined] (UNIX Only)
Forces the use of the native compiler "cc". If the variable USE_CC_DIR is also defined, the folder where the binaries are generated is given the suffix "cc".
default: not defined.

Remote Hosts

UNAMES
List of platforms for which a version of the library will be generated when the parameter compile-all is used. The possible values can be in any order, separated by blank spaces.
uname (UNIX Only)
Defines the platform-machine associations. uname can assume any of the possible values for the variable UNAME. Depends that there are aliases in DNS for each uname.

Predefined Variables

The following pre-defined variables are very useful inside the configuration file:

TEC_SYSNAME = `uname -s`
TEC_SYSARCH = `uname -m`
TEC_SYSVERSION = `uname -r|cut -f1 -d.`
TEC_SYSMINOR = `uname -r|cut -f2 -d.`
TEC_SYSRELEASE = TEC_SYSVERSION + " ." + TEC_SYSMINOR
TEC_UNAME = TEC_SYSNAME + TEC_SYSVERSION + TEC_SYSMINOR

In Windows the TEC_UNAMEs are defined as the name of the compiler to be used: vc6, vc7, vc8, vc9, dll6, dll7, dll8, dll9, gcc3, gcc4, cygw15, cygw17, mingw3, mingw4, dllw4, dllg4, owc1, bc56. They are used for both libraries and executables, but the packages available for download use the main name for the static libraries distribution only, the executable packages gets a more generic nomenclature like "Win32_bin" and "Win64_bin".

In UNIX, the variable GTK_DEFAULT is defined when GTK is the default toolkit used by IUP, this is true for Linux and BSD. If your system is too old and you don't want that set NO_GTK_DEFAULT.

In Linux, the following variables are available:

TEC_DISTNAME = `lsb_release -is`
TEC_DISTVERSION = `lsb_release -rs|cut -f1 -d.`
TEC_DIST = TEC_DISTNAME + TEC_DISTVERSION

The results are such: Ubuntu14, Ubuntu10, CentOS7, CentOS5, etc...

The following variables are also defined as a C definition so they can be used in source code:

TEC_UNAME = $(TEC_UNAME)
TEC_SYSNAME = $(TEC_SYSNAME)
$(TEC_SYSNAME) = $(TEC_SYSRELEASE)     (in UNIX Only)
TEC_LITTLEENDIAN | TEC_BIGENDIAN
TEC_32 | TEC_64 
WIN32     (in Windows, even when in 64-bits) (Except when TEC_SYSNAME=CYGWIN)
WIN64     (in Windows when in 64-bits)
MSVC8 or MSVC9   (in Windows when using the respective Visual C++)
DEBUG     (when DBG=Yes)
NDEBUG    (when DBG is not defined)

Here are some common definitions for these variables:

TEC_UNAME TEC_SYSNAME TEC_SYSARCH Byte Order Word Size System
vc9 Win32 x86 TEC_LITTLEENDIAN TEC_32 Windows + Visual C++ 9.0 (2008)
vc9_64 Win64 x64 TEC_LITTLEENDIAN TEC_64 Windows + Visual C++ 9.0 (2008)
gcc4 Win32 x86 TEC_LITTLEENDIAN TEC_32 Windows + Cygwin 1.7 gcc 4.x
cygw17 CYGWIN x86 TEC_LITTLEENDIAN TEC_32 Windows + Cygwin 1.7 gcc 4.x + Posix
mingw4 Win32 x86 TEC_LITTLEENDIAN TEC_32 Windows + MingW gcc 4.x
Linux26g4 Linux x86 TEC_LITTLEENDIAN TEC_32 Fedora Core 6 + gcc 4.x
Linux26g4_64 Linux x64 TEC_LITTLEENDIAN TEC_64 Ubuntu 9.04 + gcc 4.x
Linux26_ia64 Linux ia64 TEC_LITTLEENDIAN TEC_64 Red Hat E.L. AS 4 + gcc 3.x
SunOS58 SunOS sparc TEC_BIGENDIAN TEC_32 Sun Solaris 8
SunOS510x86 SunOS x86 TEC_LITTLEENDIAN TEC_32 Sun Solaris 10
AIX43 AIX ppc TEC_BIGENDIAN TEC_32 IBM AIX 4.3
IRIX65 IRIX mips TEC_BIGENDIAN TEC_32 SGI IRIX 6.5
MacOS104 MacOS ppc TEC_BIGENDIAN TEC_32 Mac OS X 10.4.11 [Tiger]
MacOS104x86 MacOS x86 TEC_LITTLEENDIAN TEC_32 Mac OS X 10.4.11 [Tiger]
MacOS105x86 MacOS x86 TEC_LITTLEENDIAN TEC_32 Mac OS X 10.5.4 [Leopard]
MacOS106 MacOS x64 TEC_LITTLEENDIAN TEC_64 Mac OS X 10.6.2 [Snow Leopard]

In the Tecgraf Library Download Tips you can find all definitions associated with TEC_UNAME and their respective systems/compilers.

The version suffix at the end of TEC_UNAME had to be adopted due to slight variations in the standard C library which were causing incompatibilities between static libraries generated in each of these systems.

The TEC_UNAME is a general reference for the platform. If you have the same configuration it will work fine, but it may also work in similar configurations.

Conditionals

Due to the fact that tecmake uses the GNU version of the make utility, it is possible to define in the configuration file sections conditioned to given platforms by means of a simple syntax and of the environment variable TEC_UNAME The syntax for conditionals understood by GNU make is

ifeq "ARG1" "ARG2"
   to be executed if ARG1 = ARG2
else
   to be executed otherwise
endif

The syntax to access values stored in variables is $(VARIABLE).

The part associated to the else  is optional. Note that there is no test chaining (elseif). The following example illustrates the conditioning of a given portion of the config.mak file to the SunOS55 platform:

ifeq "$(TEC_UNAME)" "SunOS55"
  ...
endif

or in a more generic form for all SunOSs:

ifneq ($(findstring SunOS, $(TEC_UNAME)), )
  ...
endif

You can also use TEC_SYSNAME to detect the platform:

ifeq "$(TEC_SYSNAME)" "Win32"
  ...
endif

Or if the code works in 32 and 64 bits:

ifneq ($(findstring Win, $(TEC_SYSNAME)), )
  ...
endif

In C, one can use:

#if TEC_SYSNAME == Win32
  ...
#elif TEC_SYSNAME == Linux
  ...
#else
  ...
#endif

#ifdef WIN32
  ...
#endif