The eCos Component Writer's Guide
Prev |  | Next

# make_object

## Name

Property make_object -- Define a custom build step, resulting in an object file that should go into a library.

## Synopsis

    cdl_option <name> {
        make_object [-library=<library>] [-priority=<pri>]  {
            <custom build step>
        }
        …
    }

## Description

When building an eCos configuration the primary target is a single library, `libtarget.a`. Most of the object files which go into this library will be generated as a result of compile properties. Occasionally it may be necessary to have special build steps for a given object file, and this can be achieved with a make_object property. The use of this property should be avoided whenever possible because it greatly increases the risk of portability problems, both on the host side because of possible problems with the tools, and on the target side because a custom build step may not allow adequately for the wide variety of architectures supported by eCos.

The make_object property takes a single argument, which resembles a makefile rule: it consists of a target, a list of dependencies, and one or more commands that should be executed. The target should be an object file. However the make_object argument is not a makefile fragment, and custom build steps may get executed in build environments that do not involve make. For full details of custom build steps see the Section called Custom Build Steps in Chapter 4.

Warning
The exact syntax and limitations of custom build steps have not yet been finalized, and may change in future versions of the configuration tools.

The make_object property takes an optional library argument. If no library is specified then the default library for the current package will be used, which will be `libtarget.a` unless the cdl_package command contains a library property.

The make_object property also takes an optional priority argument indicating the order in which build steps take place. This priority complements the dependency list, and avoids problems with packages needing to know details of custom build steps in other packages (which may change between releases). The defined order is:

Priority 0

  The header files exported by the current set of packages are copied to the appropriate places in the `include` subdirectory of the install tree. Any unnecessary copies are avoided, to prevent rebuilds of package and application source modules caused by header file dependencies.

  > Note: A possible future enhancement of the build system may result in the build and install trees being updated automatically if there has been a change to the `ecos.ecc` configuration savefile.

Priority 100

  All files specified in compile properties will get built, producing the corresponding object files. In addition any custom build steps defined by make_object properties get executed, unless there is a -priority= option.

Priority 200

  The libraries now get built using the appropriate object files.

Priority 300

  Any custom build steps specified by make properties now get executed, unless the priority for a particular build step is changed from its default.

For example, if a custom build step needs to take place before any of the normal source files get compiled then it should be given a priority somewhere between 0 and 100. If a custom build step involves post-processing an object file prior to its incorporation into a library then a priority between 100 and 200 should be used. It is not sensible to have a priority above 200, since that would imply building an additional object file for a library that has already been created.

## Example

    cdl_option XXX {
        …
        make_object {
            parser.o: parser.y
                    yacc $<
                    $(CC) $(CFLAGS) -o $@ y.tab.c
        }
    }

## See Also

Properties compile, make and library.

Prev | Home | Next
make | Up | no_define