Blame | Last modification | View Log | RSS feed
Defining a tool suite. (out of date)=========================The files in this directory defines a tool suite for use within the buildenvironment. Here a ``tool suite'' is a complete set of tools for compilation/assembly/linking etc etc. The definition takes the form of a fragment of amakefile, subsequently included into a user's makefile. This filedocuments what is expected of a definition.Throughout this document the word `target' or phrase `make target'refers to a target defined and associated with a list of commands in amakefile. The work `platform' and/or phrase `build platform' relates tothe platform on which the code being compiled/assembled/linked orwhatever will run.0.1 Trivia.==========Each suite MUST define the following macros.$(o) The extension of an object filename.$(s) The extension of an assembler source filename.$(a) The extension of a archive (library) filename.1.0 Defining a C compiler.At a minimum only the definition of the make variables $(cc) and $(o)must be provided in order to compile a C file. The rule for compilationof such a file is as follows...%.$(o): %.c $(cc_build_cmd_file)$(cc_pre)ifdef cc_error_filterifdef cc_redirect_output$(cc) $(cc_flags) $(cc_o_switch) $< > cc.out$(cc_error_filter) < cc.out$(rm) cc.outelse$(cc) $(cflags) $(cc_o_switch) $< | $(cc_error_filer)endifelse$(cc) $(cflags) $(cc_o_switch) $<endif$(cc_post)If nothing other than $(cc) is defined the above reduces to...%.$(o): %.c$(cc) $<If $(cc_build_cmd_file) is defined it names a make TARGET which willconstructs a command file for the compiler. The suite MUST define thistarget. The commands associated with it will be executed once prior toany C compilation. Therefore the command file cannot contain anythingwhich is dependent on the file being compiled, like output filenames.Only options common to all C compilations for a particular platform maybe placed into a command file. As build environment invokes makeseperately for each platform for which a module must be compiled, aseperate command file will be constructed on each occasion so platformspecific flags maybe written to a command file.If $(cc_build_cmd_file) is defined then $(cc_remove_cmd_file) MUSTalso be defined. It is also a make TARGET. The rule for thecompilation of a module is something like...<module>: <object-files> $(clean_up)where the variable clean_up is defined as...clean_up = $(cc_remove_cmd_file) $(as_remove_cmd_file) \$(ar_remove_cmd_file) $(ld_remove_cmd_file)Thus the commands of each of the targets in the list clean_up will beexecuted after all the rules required to generate <object-files> havebeen executed (but before the final commands associated with getting from<object-files> to <module>).If $(cc_error_filter) is defined it names a program through which theoutput of the compiler feed before being presented to the user. If$(cc_redirect_output) is also defined then the compiler's output willbe placed into a temporary file prior to being feed to the error fileotherwise the compiler output is piped directly into the error filter.The use of pipes under DOS doesn't really work right... if any programin a pipeline exists with an error the error code returned from thepipeline is that of the last command in the chain. Unless that is theprogram which detected the error the failure of the compilation willnot be detected and make will continue on rather than halting.If necessary the variable $(cc_o_switch) maybe defined to includewhatever is required on the command line to specify the outputfilename. Typical this will make use of the automatic variable $@ toreference the full name of the target file, something like...cc_o_switch = -o $@1.1 Setting include paths, passing in defines and the like.The variable $(include_path) contains a space seperated list of allthe directories in which the compiler should look for included files.The definition of this variable includes a reference to$(compiler_include) which maybe set by compiler definition to addinclude directories specific to the compiler.There are a number of mechanisms for passing additional information tothe compiler from rest of build environment.$(USER_CFLAGS) This maybe defined in the users template PMI file.It contains a space seperated list of -D and -I optionsto pass in additional definitions and include directoriesrespectively. No other options should be allowed in thelist as they cannot be made portable.Note that the now obsolete variable USER_FLAGS is treatedin an identical manner by the current backend definitionfiles.$(<tool-suite>_CFLAGS) where <tool-suite> is the name of thetool suite currectly being used maybe set in the userstemplate PMI file to pass flags to a particularcompiler. This may contain any options allowed by thecompiler.$(PLATFORM_CFLAGS) is defined to be $(<platform-name>_CFLAGS)where <platform-name> is the current build platformname. This is to allow the user to pass build platformspecific include and preprocessor defines into acompilation. See the document on defining a buildplatform for additional information.$(eos_platform_name) is defined by the platform specific makerules to be the EOS name for the platform.$(DEBUG) If this make variable is defined the tool suitedefinitions must arrange to define a preprocessorsymbol of the same name.$(DLVL) Debug level setting. The value of this make variable mustbe used to define the value of a preprocessor symbol ofthe same name, ie, -DDLVL=$(DLVL) must be passed to thecompiler.$(ALVL) Assert level setting. Must be treated like DLVL.USE_EOS If this variable is defined then the resulting program isto run under EOS. This probably only changes thearguments passed to the compiler by default.Outside a DOS environment all the above would simply be passed on thecommand line to each compilation. Unfortunately the command line lengthlimitation imposed by DOS makes this impossible for all but trivialcases. A tool suite must take whatever action necessary to pass all theabove information into the compiler. Typically this is done by writing acommand file in the target cc_build_cmd_file or poking something into theenvironment then using the command line $(cflags) to point the compilerat this information. For example the definitions for using the watcomtools extract all include path information from the above and construct asemicolon separated list in the variable INCLUDE which is then exportedinto the environment (the compiler looks for the environment variable bydefault). All other options are then placed into the variable WCFLAGSwhich is also exported into the environment and the variable $(cflags)set to `@WCFLAGS' to instruct the compiler to look at the variable in itsenvironment.To further assist the command sequences $(cc_pre) and $(cc_post) areincluded in the rules for translating a C file. They may be defined to beany sequence of commands using GNU-makes `define ... endef' form.2.0 Defining an assembler.%.$(o): %.$(s) $(as_init_target)$(as_pre)$(show_environment)ifdef as_error_filterifdef as_redirect_output$(as) $(aflags) $(as_o_switch) $< > as.out$(as_error_filter) < as.out$(rm) as.outelse$(as) $(aflags) $(as_o_switch) $< | $(as_error_filer)endifelse$(as) $(aflags) $(as_o_switch) $<endif$(as_post)3.0 Defining an archiver.%.$(a): $(ar_init_target)$(ar_pre)$(show_environment)$(ar) $(arflags) $(ar_o_switch)$(ar_post)