Make flags

The arguments passed to pkgconf.tcl and the configuration options in the header files control what code gets compiled. It is also possible to control how the code gets compiled, in other words what compiler flags are used.

In eCos the various compiler flags are organized into five categories: architectural flags such as -mcpu=860, which provide more specific information about the target hardware; diagnostic flags such as -Wall and -Wstrict-prototypes which control the warnings that the compiler may generate; flags related to optional aspects of the language, for example -fno-rtti to suppress the use of run-time type information which is not needed by eCos; options that affect code generation such as -O2; and anything else.

For each of these five categories, it is possible to specify whether the flags should be applied only when compiling C code, only for C++ code, only when linking test executables, or for all invocations of the compiler. This gives a total of 20 variables that can be manipulated.

ARCHFLAGSCARCHFLAGSCXXARCHFLAGSLDARCHFLAGS
ERRFLAGSCERRFLAGSCXXERRFLAGSLDERRFLAGS
LANGFLAGSCLANGFLAGSCXXLANGFLAGSLDLANGFLAGS
DBGFLAGSCDBGFLAGSCXXDBGFLAGSLDDBGFLAGS
EXTRAFLAGSCEXTRAFLAGSCXXEXTRAFLAGSLDEXTRAFLAGS

The variable CXXERRFLAGS should be used for diagnostic-related compiler flags that only apply when compiling C++ code. An example of this would be -Woverloaded-virtual. Similarly, DBGFLAGS is intended for compiler flags related to code generation that should be used for all compiles and links, for example -O2.

A number of compiler flags are highly recommended when building eCos, although the exact details will vary from platform to platform. When pkgconf.tcl generates or updates a build tree it will write these default flags to the file pkgconf.mak in the pkgconf subdirectory of the build tree.

There are a number of different ways in which the default sets of compiler flags can be overridden — the most appropriate one to use depends very much on the situation.

  1. It is possible to override any of the variables on the make command line, for example:

    
	      $ make DBGFLAGS=-O4 

    This has the disadvantage that the information is not stored anywhere. If it is necessary to do multiple builds with the same compiler flags then you must remember to pass the same command line arguments to make every time. If you forget to do so at any time then the results can be confusing and irreproducible.

  2. It is possible to set environment variables, for example:

    
	      $ DBGFLAGS=-O4
    	      $ export DBGFLAGS 

    (The exact command line will depend on the shell you use).

    This information is somewhat more persistent than the command line argument approach, especially if the environment variables are set in the shell's startup files rather than in a running shell. This approach has the big disadvantage that the settings may affect other build systems, for example whatever environment is used to build the application itself. Another, but more minor, disadvantage is that it is very easy to forget that an environment variable has been set, leading to confusion if you are trying to work out exactly why a particular compiler flag is being used.

  3. It is possible to specify any of the variables on the pkgconf.tcl command line, for example:

    
	      $ tclsh BASE_DIR/pkgconf.tcl --target=mn10300 DBGFLAGS=-O4 

    Any variables specified in this way will end up in the pkgconf.mak file in the build tree's pkgconf directory, and will persist until you run pkgconf.tcl again with a different value for the variable. This approach has the advantage that no files need to be edited, but it has the minor disadvantage that it is somewhat more difficult to restore the default settings.

  4. You can edit the file makevars in the build tree's pkgconf subdirectory. This file contains a number of lines resembling the following:

    
   ifeq ($(DBGFLAGS),)
       DBGFLAGS 	:= $(PKGCONF_DBGFLAGS)
       #DBGFLAGS	:=
       endif 

    The ifeq/endif test makes sure that the makefile variable DBGFLAGS is not already defined, either on the command line or in an environment variable. If it is not defined then the variable will normally be set on the next line, and the value that will be used is the default value which pkgconf.tcl has written to the pkgconf.mak file. It is possible to comment out this line, uncomment the next line, and fill in appropriate compiler flags.

    
   ifeq ($(DBGFLAGS),)
       #DBGFLAGS 	:= $(PKGCONF_DBGFLAGS)
       DBGFLAGS	:= -O4
       endif

    It is now possible to switch between the default and the custom behavior very easily, simply by moving the comment character between the two lines.

    Editing the makevars file like this is the most flexible and robust mechanism for controlling compiler flags, but it requires a bit more work on your part.

    The makevars file contains a number of other makefile variables that you can edit. For example, it is possible to change the name of the compiler that will be used for all the builds.