public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@redhat.com>
To: geetham@india.hp.com
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] Using config tool for other projects
Date: Fri, 06 Jul 2001 05:43:00 -0000	[thread overview]
Message-ID: <200107061243.f66Chc406312@sheesh.cambridge.redhat.com> (raw)
In-Reply-To: <3B456001.56F04095@india.hp.com>

>>>>> "Geetha" == Geetha Manjunath <geetham@india.hp.com> writes:

    Geetha> Hello all,
    Geetha> The ecos config tool and its language seem to be nice for
    Geetha> configuring any fairly complex source code. Are there any
    Geetha> instances of the config tool + CDL being leveraged for
    Geetha> projects other than ecos ?

There have been some instances where the CDL technology was considered
for other projects, but none of them got past the investigation and
prototype stage.

CDL is designed for a very specific componentized model of software
development. If the intended system is fundamentally monolithic in
nature, CDL will not be appropriate. If the intended system will be a
set of packages with dependencies, CDL may be appropriate. Also, the
eCos configuration technology is intended to allow users to manipulate
all the configuration options, unlike something like autoconf where
the intention is that the tool adapts to the environment with minimal
user intervention required. Hence CDL would not really be appropriate
as a technology for replacing autoconf, the underlying goals are
different.

There are some areas in the current technology where the code is
biassed specifically towards eCos. For example the makefile generation
code has built-in knowledge of the typical eCos development process.
Areas like that would have to be analysed and made more generic, if
you wanted to re-use the technology for different purposes. There are
also many areas where the current implementation of the CDL technology
is incomplete: barely sufficient for current eCos needs, but no more
than that.

If you have some specific project in mind for which CDL technology
might be appropriate, I would certainly be interested in finding out
more. 

Bart

      parent reply	other threads:[~2001-07-06  5:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-05 23:51 Geetha Manjunath
2001-07-06  3:20 ` Julian Smart
2001-07-06  5:43 ` Bart Veer [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200107061243.f66Chc406312@sheesh.cambridge.redhat.com \
    --to=bartv@redhat.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    --cc=geetham@india.hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).