[ECOS] CDL parent target+options?

Bart Veer bartv@redhat.com
Tue Apr 18 08:43:00 GMT 2000

>>>>> "Liviu" == Liviu Ionescu <ilg@livius.net> writes:

    Liviu> is there any way to define targets based on a parent target
    Liviu> plus some different options?

    Liviu> for example, I have a target iq80960rx that points to a
    Liviu> hal<...>.cdl definition for building the flash version of
    Liviu> the system and I would like to define a new target, let's
    Liviu> say iq80960rx_ram that does exactly the same thing, except
    Liviu> defines CYG_HAL_STARTUP="RAM" so I end up with the ram
    Liviu> version of the system.

    Liviu> (I know that the configuration tool can be used to fine
    Liviu> tune options, but... it does not run on unix yet, and
    Liviu> manually configuring the .ecc file is not much fun)

The "correct" way to do this is indeed to modify the .ecc file, either
by a script, manually, or inside the GUI. A Unix version of the GUI
config tool is of course planned. We expect that, most of the time,
people will use just one type of startup, probably RAM. Switching
startups should be a fairly rare event, and there is no special
support for it in the current tools.

It is possible to achieve what you are after via the ecos.db database,
using something like the following:

    target iq80960rx_ram {
        set_value CYGHWR_HAL_STARTUP "RAM"

This sort of thing is fine for development purposes, but for
contributed entries to ecos.db I would expect to see just one target
definition per board.

There are other ways of achieving the same effect using templates, or
by generating a partial savefile and using `ecosconfig import'. 

    Liviu> -/-/-

    Liviu> more or less related to the above, is there any way to have
    Liviu> a better control on the build process? for instance I would
    Liviu> like to add new targets to the main makefile.

Not at this time, I am afraid. Enhancing the configuration and build
technology along these lines (and quite a few other lines as well) is
on the TODO list. Providing support for additional targets could
be done by an option to the existing CDL "make" property, or by a new

However I do want to tread carefully here. One of the goals of the
eCos build system is to keep things simple for ordinary application
developers. Right now there is only one main target, and it generates
the library and everything else needed to build applications. Allowing
the build system to generate lots of targets could make things more
confusing for typical application developers. I do not want to see the
configuration technology grow into some kind of IDE for application
development, that is not its purpose.

    Liviu> before switching to ecos my previous build tools allowed
    Liviu> separate debug/release targets, and in each case the link
    Liviu> phase was doubled, producing both flash and ram versions
    Liviu> from exactly the same object files (I personally believe it
    Liviu> is not a good idea to propagate the ram/flash information
    Liviu> into header files and have the object files built
    Liviu> differently; distinct *.ld files are enough to
    Liviu> differentiate the two cases).

On some targets only the .ld files would be affected by startup
selection, but on other targets there may have to be code changes as
well. Again, we feel that typical application developers will work
with just one type of startup for most of the development cycle - this
could be an incorrect assumption, and given sufficient evidence we
would rethink the issue. We are also working on the assumption that
changing the configuration and rebuilding is very easy - this is not
quite true yet for Unix users.


More information about the Ecos-discuss mailing list