Folder Organization

Concerning the folder structure, all tecmake needs to run is a folder where the source files will be placed. The diagram below illustrates the folder structure used:

Folders include, obj and lib are created automatically, as well as the subfolders related to the platforms. The folder src is the one from which tecmake must be executed (note: this folder does not need to have this name). Folder include will contain the exported inclusion files associated to the variable EXPINC. This folder will contain only links to the files in folder src. Similarly, the folder lua will exist only when the variable EXPLUA is defined and will also only contain links to files in the src folder.

tecmake was designed to have folder src as reference in the hierarchy presented above, that is, the user will have to work with the current file being src, from where s/he can easily access the product's source files.

Compilers Settings

These are the compiler parameters used internally by Tecmake.


-Wall (always)
-g (DBG)
-O2 (OPT)
-m64 -fPIC (BUILD_64)
-bundle -undefined dynamic_lookup   (for shared code libraries in MacOS X)
-dynamiclib -install_name lib$(TARGETNAME).dylib    (for dynamic libraries in MacOS X when BUILD_DYLIB=Yes)

Open Watcom

-od -w4 -5r -bt=nt -mf -e25 -zq (always)
-d2 (DBG)
-ot (OPT)
-b -c -n -q -p=512 (libraries)
-bm -br (USE_DLL)


-v -N -x -xp (DBG)
-O2 (OPT)

Visual C++

-W3 -GX (always)
-Z7 -Od -GZ (DBG)
-MLd (DBG)

O2 = Maximize Speed
Z7 = C7 Compatible
Gd (default) = cdecl calling convention 
GZ = Run-Time Error Checks
LTCG, GL = Whole Program Optimization
M* = Run-Time Library (options are mutually exclusive)
     (There is no single thread since VC8, USE_MT=Yes is always set)
_CRT_SECURE_NO_DEPRECATE is defined for VC8 and newer.
To enable automatic manifest file generation and embedding in VC8 or VC9 use GEN_MANIFEST=Yes.
To enable C++ additional definitions for RTL functions for VC8, and newer, use CPP_NARROW_INLINES=Yes.

Embedding Lua Files in Binaries

You often do not want to distribute the application's Lua files open to anyone. In this case, use the variable SRCLUA to define which files will be embedded using an inclusion-file format (by bin2c).

LOHs (Less Flexible - Hard to maintain portability - Faster)

Lua sources can be compiled to Lua Byte Code (by luac) before being embedded. But notice that the binary files created by luac are portable only among architectures with the same word size and byte order, and byte code generated by luac is not compatible with byte code generated by LuaJIT for instance.

In your code, use a code similar to the following to include files:

#ifdef DEBUG
  luaL_dofile(L, "test.lua");
#ifdef TEC_64
#include "test_be64.loh"  // big endian (motorola/network) on 64-bits
#include "test_be32.loh"  // big endian (motorola/network) on 32-bits
#ifdef TEC_64
#ifdef WIN64
#include "test_le64w.loh"  // little endian (intel) on 64-bits (Windows)
#include "test_le64.loh"  // little endian (intel) on 64-bits
#include "test.loh"       // little endian (intel) on 32-bits

But this must be done inside an existent function. Usually an initialization function called only once.

This way, in the debug version, the Lua files will be text files, easy to work on, and the final version will use the binary files embedded in the code.

Notice that in 64-bits Windows "long" is still 32-bits, so the LOHs are not compatible with LOHs generated in 64-bits UNIX.

If you want to ignore the suffixes and use only one file, just define "LO_SUFFIX = " in your "config.mak" file.

Another option is to use the USE_LOH_SUBDIR definition and control the LOH inclusion inside the makefile instead of inside the source code. The code above can then be changed to:

#ifdef DEBUG
  luaL_dofile(L, "test.lua");
#include "test.loh"       // all LOHs have the same name, USE_LOH_SUBDIR will add to INCLUDES accordingly 

LHs (More Flexible - Easy Portability - Slightly Slower)

This is a much more simpler approach. Although slightly slower than LOHs (depending on the original Lua file size), when SRCLUA is defined and NO_LUAOBJECT is also defined, the Lua source files will be directly embedded using bin2c. The generated .lh files are portable among platforms and compatible with LuaJIT.

Using Manifests

To enable automatic manifest file generation in VC8 or VC9 use GEN_MANIFEST=Yes. But if you define your own manifest file and include it in a resource file to be linked with the application executable or DLL then you may have problems when compiling the same project with VC8 and VC9.

The solution is to use a selective include in the resource file using a few existing definitions.

Example for a DLL:

#ifdef MSVC8
2 24 "lua_dll8.manifest"
#elif MSVC9
2 24 "lua_dll9.manifest"

Example for an Executable:

#ifdef MSVC8
1 24 "wlua_dll8.manifest"
#elif MSVC9
1 24 "wlua_dll9.manifest"

If you build your application or DLL for both 32 and 64 bits then we suggest using in the manifest a generic processor architecture:


Standalone as a Makefile for POSIX systems

In UNIX/Posix, Tecmake can be distributed together with the source code with no need for an additional installation. Simply copy the file "tecmake.mak" to your source code and rename it to "Makefile".

To build the target simply do "make" on the command line. The Tecmake parameters can be used simply as doing "make clean". But notice that not all parameters are available (see note bellow).

To build several targets, keep the original name and create a new file called "Makefile" with contents similar to the following:

all: target1 target2 target3

	@$(MAKE) --no-print-directory -f tecmake.mak                       #(to let Tecmake use "config.mak")

	@$(MAKE) --no-print-directory -f tecmake.mak MF=target2            #(to make Tecmake use "target2.mak")

	@$(MAKE) --no-print-directory -f tecmake.mak MF=target3            #(to make Tecmake use "target3.mak")

Then you can use your own parameters to build different targets.

As a general rule the following are not supported without installation: the "*-all" parameters and remote build.

If you are building a library or application that depends on a Tecgraf library like IUP, CD or IM, then define the TECTOOLS_HOME variable inside your "config.mak". It points to the base path where those libraries are installed. It can be a relative path like "../..".

IMPORTANT: This form of Makefile is know NOT to work on the systems: FreeBSD, AIX and IRIX. There are unsolved syntax problems on those systems when using the "($shell uname)" command.

Standalone as a Makefile for MingW and Cygwin systems

Similar to the Posix counterpart, you can use the "tecmakewin.mak" file without installing Tecmake, but you will have to specify the TEC_UNAME variable before using it, or by setting it in the environment or by passing it as a parameter. For example:

make -f tecmakewin.mak TEC_UNAME=mingw4
make -f tecmakewin.mak TEC_UNAME=gcc4         (Cygwin building for Win32)

Also you will need to define the location of the compiler, for example (notice the use of slash):

set MINGW4=c:/mingw
set GCC4=c:/cygwin

Visual C++ Minimum Installation

Here is a small tutorial on how to setup a minimum Windows build system to use Tecmake in Windows XP and Microsoft Visual C++ 2008, but can be used for newer compilers and systems.

shortpath "C:\Program Files\Microsoft SDKs\Windows\v6.1"
shortpath "C:\Program Files\Microsoft Visual Studio 9.0\VC"
set TECMAKE_PATH=c:\tecgraf\tecmake              (this is the only place where backslash is used)
set TECMAKE_HOME=/cygdrive/c/tecgraf/tecmake
set VC9SDK=C:/PROGRA~1/MICROS~2/Windows/v6.0A

The simplest way to use it is to run the "CMD Shell" or "Build Environment" item in the "Microsoft Windows SDK" start menu folder.

 Then at the folder of your project with the "config.mak" file, type at the command line:

tecmake vc9

Notice that if Visual C++ Express is not installed, the Windows SDK already includes the necessary command line compilers. But then they will be located in the same folders of the Windows SDK binaries, and both variables VC9 and VC9SDK, for instance, must point to the same folder.

If using a regular CMD session, and the following error occur:

/cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin/cl.exe: error while loading shared libraries: mspdb80.dll: ca
nnot open shared object file: No such file or directory

Then add some folders to the PATH like this (according to each Visual Studio installation):

set VS9=C:\Program Files (x86)\Microsoft Visual Studio 9.0
set VS9SDK=C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin
set PATH=%VS9%\Common7\IDE;%VS9%\VC\BIN;%VS9%\Common7\Tools;%VS9%\Common7\Tools\bin;%VS9%\VC\VCPackages;%VS9SDK%\bin;%PATH%

MingW Minimum Installation

Here is a small tutorial on how to setup a minimum Windows build system to use Tecmake and MingW. No need to install Cygwin.

set TECMAKE_PATH=c:\tecgraf\tecmake
set TECMAKE_HOME=/cygdrive/c/tecgraf/tecmake
set MINGW4=c:/mingw

Start a command line with "cmd", then at the folder of your project with the "config.mak" file type in the command line:

tecmake mingw3