Why is it that every time I change file config.mak the dependencies are recomputed?
Actually, the dependencies need only be recomputed whenever one of the variables SRC or INC (or both) is redefined. However, tecmake cannot distinguish a change made in tecmake that effectively changes one of these variables from a change that affects only other variables. Therefore, every time the date of the last change made to file config.mak is more recent than that of the file dependencies, the latter will be regenerated.
One way to avoid this is to update the date of the file dependencies by means of the command "touch dependencies".
REMEMBER: Use this resource only when you are sure that changes in the file config.mak do not have any side effects on file dependencies.
In some cases, the list of dependencies generated by tecmake to the distribution makefile (option dist) is not correct. This happens in files included as
#include "file"
which are not located in the same folder as the source files that refer to them and only in cases where the inclusion-files folder specified in file config.dist differs from the one specified in config.mak.
If the dependencies file does not exist, executing the rule depend will generate it twice. This happens because file dependencies is automatically created if it does not exist, and the rule depend deletes it in order to reconstruct it.
I often change my config.mak file, but the variables SRC and INC are seldom changed. Is there a way to prevent the dependencies from being recomputed?
Yes. Apart from the procedure presented in the previous question, the parts in config.mak that are changed more often can be isolated in a separate file with an arbitrary name, and config.mak can be instructed to "include" this file. This way, changes made to this file will not impact config.mak, preventing dependencies from being recomputed.
In order to include a makefile inside another, simply use command "include":
include file
Is it possible to generate object files (.o) in a different folder from the default? What about the libraries?
Yes. For object files to be created in an arbitrary folder, the variable OBJROOT simply has to be redefined in the config.mak file. tecmake will place the .o files in the folders [OBJROOT]/[platform]. For example, if OBJROOT = /tmp/costa/obj/pgm, the .o files will be placed in the folders
/tmp/costa/obj/pgm/Linux20
/tmp/costa/obj/pgm/IRIX62
/tmp/costa/obj/pgm/[...]
Note: The subfolders corresponding to the platforms are automatically created by tecmake.
Regarding binary files of executables and libraries, there is a variable analogous to OBJROOT called TARGETROOT. One should take special care not to place libraries that will be accessed by other users in local folders, which would restrict their use. Also TEC_UNAME_DIR can be redefined for better control of the final destination folder.
ATTENTION: Using the variables OBJROOT and TARGETROOT has side effects over options of tecmake that imply remote compilation (all, rebuild-all) and that impact more than one platform (clean-all-obj, clean-all). When these variables point to local folders, those options stop working properly. For example, option rebuild-all would act only on the object files of the current platform.
Sometimes I have to run tecmake attributing to some of the variables values different from those listed in the config.mak file. Is there a way to make this without having to edit the file?
Yes. The make utility accepts variables to be redefined in the command line. Such values have precedence over those in the makefile (or, in the case of tecmake, config.mak). The syntax is:
make var=value [var=value...] parameters...
Some examples:
IMPORTANT: In Windows one must specify parameters using quotation marks: tecmake "VAR=valor"
.
(a) Can I specify more than one parameter for tecmake? (b) In what order?
(a) Yes. The make command accepts several targets as parameters, executing them sequentially. By target we mean the name of a rule to be executed (in the case of tecmake, any of the parameters described in section Reference). Variable redefinitions (see the previous question) are not targets.
(b) For parameters with no side effects (most of them), yes. An example of a parameter that does have side effects is clean-all: its inclusion in a command line will invalidate the result of any other parameter that has preceded it.
NOTES:
tecmake CC=gcc FLAGS=-g SunOS static
will generate both versions (static and dynamic) of the library to the SunOS platform. The parameter static will have local impact, causing only the static version of the library to be generated for the Linux platform. In both cases (remote and local execution) the compiler used will be gcc and the code will have debug information.
When I generate a distribution makefile (by means of the command "tecmake dist"), my variable INCLUDES, defined in config.mak as
INCLUDES = $(IUP)/include
is defined as
INCLUDES = /home/t/tecgraf/lib/iup/include
Is it possible to preserve the original definition (without macro-expansion)?
No. Once a variable is defined, it is impossible to access its value without macro-expansion taking place (even in the GNU make). However, using the file config.dist, this problem can be avoided.
The config.dist file is added, verbatim, after the definition of variables in the distribution makefile. This way, definitions present in the former will have precedence over any other made in the beginning of the latter. In the example above, the distribution makefile would contain two definitions for the variable INCLUDES. Since the order is relevant, the last definition (in the config.dist file) would be the one considered, thus assuring the desired effect.
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 compiled for Lua Byte Code (by luac) and then placed in an inclusion-file format (by bin2c). "The binary files created by luac are portable only among architectures with the same word size and byte order."
In your code, use a code similar to the following to include files:
#ifdef DEBUG luaL_dofile(L, "test.lua"); #else #ifdef TEC_BIGENDIAN #ifdef TEC_64 #include "test_be64.loh" // big endian (motorola/network) on 64-bits #else #include "test_be32.loh" // big endian (motorola/network) on 32-bits #endif #else #ifdef TEC_64 #ifdef WIN64 #include "test_le64w.loh" // little endian (intel) on 64-bits (Windows) #else #include "test_le64.loh" // little endian (intel) on 64-bits #endif #else #include "test.loh" // little endian (intel) on 32-bits #endif #endif #endif
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.
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" #endif
Example for an Executable:
#ifdef MSVC8 1 24 "wlua_dll8.manifest" #elif MSVC9 1 24 "wlua_dll9.manifest" #endif
If you build your application or DLL for both 32 and 64 bits then we suggest using in the manifest a generic processor architecture:
processorArchitecture="*"