public inbox for
 help / color / mirror / Atom feed
From: Grant Edwards <>
Subject: [ECOS] Re: eCos Configuration Tool clewan and rebuild
Date: Thu, 16 Jun 2016 17:09:00 -0000	[thread overview]
Message-ID: <njumgc$p71$> (raw)
In-Reply-To: <07FFDDED6CBCCE4E9FBD46AEC3EBFD4F02C50BB3@exchange>

On 2016-06-16, Michael W. Ellis <> wrote:
> I have inherited a project based on eCos 2.0.98 and have reached a point
> where I need to rebuild my library.  Most of the folks who originally
> worked on this project are no longer with the company and our internal
> documentation is scarce at best.
> My understanding is that the eCos Configuration Tool is used to make
> changes to a .ecc file, and then to use this file to build the library.

Yes.  However, there are two different ecos configuration tools.  A
command line one, and a GUI one (there might be multiple similar but
different look/feel GUI ones, I don't really know).

For all our actuall production code, we use the command-line
ecosconfig utility exclusivly.  That way you can write a shell script
that calls the ecosconfig utility to generate an .ecc file from
scratch and then creates the build tree.

That shell script is then placed under source control just like the
rest of source code.  IMO, relying on a GUI tool and
accurate/repeatable human clicking for building production code is a
huge mistake.  You can place the .ecc file under version control if
you want, but (IMO) it's far more important that the script that
_builds_ the .ecc file is under source control.

> I have located the .ecc file for my project and have attempted to
> rebuild the library but something seems to be amiss.  I see the
> extras.o, libextras.a and libtarget.a files in _install/lib change
> but the target.ld and vectors.o files remain unchanged.

You probably need to start with a new build tree.

> On one of my changes I updated linker-related files for my hardware
> in the eCos repository, but the linker files never seem to be
> regenerated.

Only the .c files are used directory from the repository.  Most other
files get processed and then copied into the build tree.

> If I manually delete target.ld and rebuild the library then a new
> linker file is created.
> Is there something I'm missing here?  I have tried cleaning

What do you mean by "cleaning"?

> and then building but nothing seems to make a difference to the
> linker file.

If you're using the GUI config tool, I can't really help.  If you're
using the command-line one, start with an empty directory.  Your
script should start with

  ecosconfig new <platform>

then, as needed

  ecosconfig add <package>
  econsonfig del <package>

and finally change/set/clear whatever package options you need to

  cat >.tmp$$.cdl <<EOF
  cdl_component CYGSEM_KERNEL_SCHED_TIMESLICE {user_value 0}
  cdl_option CYGPKG_IO_NFILE {user_value 256}
  cdl_option CYGNUM_FILEIO_NFILE {user_value 256}
  cdl_option CYGNUM_FILEIO_NFD {user_value 256}
  cdl_option CYGPKG_NET_TFTP {user_value 0}

  ecosconfig import .tmp$$.cdl

That produces the .ecc file. Now you create the build tree

  ecosconfig tree

Now you have a "build tree" that contains things like include files,
Makefiles, linker scripts, and basically everything except the .c files.

Finally do the build


If you want to rebuild because

 0) you changed a CDL file: start over completely at the "ecosconfig
    new" step in an empty directory.

 1) you changed a .h file or linker script or memory map file: start
    at the "ecosconfig tree" step in a directory containing nothing
    but the .ecc file.

 2) you changed a .c file: you can generally just run "make" again.

Grant Edwards               grant.b.edwards        Yow! I'm in direct contact
                                  at               with many advanced fun

Before posting, please read the FAQ:
and search the list archive:

  reply	other threads:[~2016-06-16 17:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-27 13:29 [ECOS] cyg_flag_timed_wait doesn't seem to work as expected Michael W. Ellis
2016-05-27 15:53 ` AW: " Richard Rauch
2016-05-27 16:31 ` Nick Garnett
2016-05-27 20:46   ` Michael W. Ellis
2016-06-16 13:26 ` [ECOS] eCos Configuration Tool clewan and rebuild Michael W. Ellis
2016-06-16 17:09   ` Grant Edwards [this message]
2016-06-16 21:18     ` [ECOS] " Michael W. Ellis
2016-06-16 21:41       ` Grant Edwards
2016-06-16 23:05         ` Alex Schuilenburg
2016-06-17  4:05           ` AW: " Richard Rauch
2016-06-17 10:10             ` Alex Schuilenburg
2016-06-18 12:01               ` AW: " Richard Rauch
2016-06-18 13:20                 ` Alex Schuilenburg
2016-06-30 14:53         ` [ECOS] Input from debug console Michael W. Ellis
2016-06-30 16:01           ` Michael W. Ellis
2016-06-30 16:09             ` Evgeniy Dushistov
2016-06-30 17:52             ` [ECOS] " Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='njumgc$p71$' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).