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.
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.
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