This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: eCos update issues


>>>>> "Kenneth" == Kenneth Porter <kenneth_porter@kensingtonlabs.com> writes:

    Kenneth> I followed the instructions on the CVS page to update
    Kenneth> eCos and the config tool.

    Kenneth> The registry file for the new configtool lacks the FADS
    Kenneth> platform. What are the registry entries for, and do I
    Kenneth> need to manually add a FADS entry?

I have been given the following information about the registry
entries:

    > The registry contains info required for the 'Run Tests' feature.
    > Specifically, it provides a mapping between the HAL platform
    > package name and a testing identifier. It also provides
    > information on whether tests should be run in a simulator or on
    > hardware. FADS users will need to create a registry key as
    > follows:
    >
    > HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\eCos\1.2.1\Platforms\PowerPC-fads
    >
    > Then create a String Value named "Macro" under this key
    > containing the data "POWERPC_FADS".

So there is no need to update the registry in order to build eCos for
the FADS board, only if you want to use the configuration tool's
`Run Tests' facility (see the documentation for more details of that).

    Kenneth> CVS instructions need example commands for Windows users.

I am not aware of any major differences between running CVS under
Windows or under Unix, but have never tried using it under Windows
myself. The various resources listed on
http://sourceware.cygnus.com/ecos/anoncvs.html may provide more
information. Also a book on CVS was published recently, see
http://cvsbook.red-bean.com/ for details.

    Kenneth> It wasn't clear to me whether I want to overwrite my
    Kenneth> existing eCos setup with the CVS one or create a new
    Kenneth> directory tree paralleling it. I ended up overwriting the
    Kenneth> existing tree. Being new to CVS, I was a bit uncertain
    Kenneth> about the warnings displayed.

The design of the eCos directory structure largely allows the
anonymous CVS sources and different eCos releases to co-exist in one
big tree. The component repository (or source tree) is organized with
separate directories for each package, and there is a version
directory level just below that. So you could end up with something
like:

   kernel
     current
       src
       include
       tests
       ...
     v1_1
       ...
     v1_2_1
       ...

The anonymous CVS sources use `current' as the version number. It
would be necessary to use the cvsignore facilities to stop CVS from
trying to do anything with the release versions, e.g. asking if you
want to check them in, but that is a detail.

In practice this functionality is not yet functional. The various
configuration tools in the current release do not fully support having
multiple releases of a package in one component repository. There are
also some issues related to the global database files, `packages' and
`targets', and to the build-related files in the pkgconf subdirectory.
Potentially there are also backwards compatibility problems for the
host tools. These issues will be resolved in some future release, but
for now it is recommended that you use completely separate trees for
release versions and the anonymous CVS sources. I shall add a note to
the web pages about this.

Bart Veer // eCos net maintainer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]