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.