Subversion Repositories or1k

                                TODO List

                                ---------

Minor

-----

1) savefile support. Add option handling to the remaining savefile

   commands, even if no options are currently defined.

2) remember unrecognised options so that they can be written back

   when the savefile is regenerated. Perhaps add option details

   to the header?

3) allow re-parenting below "". Make the orphans container disabled?

4) get limbo working

5) make cdl_interfaces into containers? How about cdl_options as well,

   to avoid reparenting problems?

   cdl_interfaces as containers is actually a problem because interfaces

   are part of the core, and hence do not know about the existence of

   options and components.

6) allow components and options to be used interchangeably in savefiles.

7) ecosconfig, create a paths file with details of the source tree

   location etc? How about reporting the paths?

   >     Huge> How about: put information about the source tree into the savefile BUT you

   >     Huge> can put

   >     Huge>  ecosconfig --srcdir=/home/hmt/work/ecc/net/ecc/ecc

   >     Huge> and it'll say "Oi!  You've changed the repository!  Override [y/n]?"

   >     Huge> That lets you move them 'round.

   >

   > That is a possibility, but I am reluctant to add any interactive

   > facilities to ecosconfig just yet

   OK, instead:

        % ecosconfig --srcdir=/home/hmt/work/ecc/net/ecc/

        ecosconfig: Oi!  You've changed the repository!  Quitting.

        ecosconfig: [Hint: Use --new-srcdir to override.]

        % ecosconfig --new-srcdir=/home/hmt/work/ecc/net/ecc/

        ecosconfig: new repository selected: /home/hmt/work/ecc/net/ecc/

        % _

   There's interactive and interactive... ;-)

   [*enable anyone? ;-)]

8) savefiles, if an interface has no implementors then say so.

9) CDL filenames in the savefile? This might be useful for people

   wanting to look at the CDL sources, although all the interesting

   information should already be in the savefile.

10) what happens if a source file is listed for two separate options?

11) define -format="\\\"%s\\\"" XYZ

    This seems to do the wrong thing. Consider:

    cdl_option CYGNUM_LIBC_MAX_LOCALE_NAME_SIZE {

        define -format="\\\"%s\\\"" XYZ

        ...

    }

    The output is:

    #define CYGNUM_LIBC_MAX_LOCALE_NAME_SIZE "16"

    #define XYZ_16

    BLV - may have been fixed on Feb 14th

12) define -format="\"%s\"" XYZ

    This gives an internal error. Should it?

13) make-object, check for priorities less than 200. It is not

    sensible to build an object after the library has been

    constructed. Also check that the target is a .o file.

14) exported header files. Suppress obvious problems such as

    CVS subdirectories and files ending with ~. See pkgconf::locate_files.

15) diagnostics for inappropriate templates, e.g. the stubs template on simulators.

16) custom build steps and generating exported header files.

    Priorities of custom build steps that should go before header file

    generation?

    Use of include_files property.

17) what happens when several packages specify the same define_header?

18) evalexception conflicts. What should happen if the node is disabled or inactive?

    Especially if it is the default_value expression that is causing the problem.

19) add diagnostic callback support to the inference engine so that I

    can figure out what is going on.

20) make version comparison completely case insensitive, to avoid

    problems on some file systems.

21) configure magic to cope with Debian TCL organization.

    See http://sourceware.cygnus.com/ml/ecos-discuss/2000-06/msg00094.html

22) add version number #define's to pkgconf/system.h, to allow

    application code to adapt to different versions of a package.

    http://sourceware.cygnus.com/ml/ecos-discuss/2000-06/msg00140.html

Intermediate

------------

1) integrate the makefile generation support into libcdl.

2) implement the Tcl interface to the CDL data, especially tcl_get

   and the appropriate Tcl variables.

3) full definition of custom build steps and the build procedure

   generally, including working out what should happen for

   compiler flags.

   Dependency analysis in custom build steps.

4) get safe interpreters working, and make sure that only safe

   file I/O operations are permitted.

5) Improve diagnostic messages, including line numbers.

6) extend the inference engine to support more operators.

7) support disabled conflicts.

8) full implementation of interfaces, including automatic creation.

9) text aliases for legal_values lists?

10) savefiles do not list `implements' properties

11) ecosconfig verbosity. Add --silent and --verbose modes?

12) header file dependencies. From Jesper and others:

    One alternative way of handling this is the way it's done in Linux

    (which happened around 2.2.?, I think, and made for some

    phenomenal build speedups):

     grep each source file foo.c for use of CYGxxx_ macros. Cat this list

     into .foo.c.config_deps (or similar) with proper mangling so it

     becomes a GCC dependency file (for foo.c) on "option files".

     Each option, opt_name, thus adds a dependency on

     $build/config_deps/CYGxxx_opt_name. Whenever changing the config,

     touch the relevant config_deps/ files.

     In short: when making general source file dependencies, exclude any

     dependencies on $install/include/pkgconf/* and replace with

     appropriate $build/config_deps/* dependencies. That makes for one

     smoooking fast dependency system. It doesn't get finer-grained than

     this.

13) friend packages, allowing one package to see the implementation

    details of another. Also, handle documentation links between these.

14) API clean-up. Eliminate the confusion between "value" and the data part of

    a bool/data pair.

Major

-----

1) implement and integrate a proper infrastructure. Generally sort out

   the host-side build tree, including making libcdl into a Tcl

    package.

2) sort out the test suites.

3) std::bad_alloc exceptions. These can happen just about anywhere.

   Lots of places need to be hardened against this to avoid memory

   leaks. A completely robust system is probably not possible

   because cancelling a transaction may involve memory allocation.

4) general code walk through to look for obvious inefficiencies, e.g.

   passing things by value rather than by reference.

5) generalise the build support for other languages such as Java.

6) implement a proper database and associated admin tool.

7) improved autoconfiscation support, in particular finding the

   appropriate platform-specific library support.

8) a suitable naming convention for data members and for arguments to

   inline functions should be adopted, to prevent collisions with

   #define'd symbols in application land. Possibilities include

   _X_ and __X.

9) work out how to extend Tcl to provide line number information.

10) i18n support.

11) currently the data type cdl_int is defined to be 64 bits. This should

    probably be changed to arbitrary precision, so that e.g. processors

    which can perform 128 bit arithmetic can be adequately supported.

12) extend the CDL expression syntax with e.g. string operators. This

    will impact the inference engine.

13) add an interactive mode to ecosconfig resolve, allowing users to

    confirm or cancel solutions?

//===========================================================================

//####COPYRIGHTBEGIN####

//

// ----------------------------------------------------------------------------

// Copyright (C) 1999, 2000 Red Hat, Inc.

//

// This file is part of the eCos host tools.

//

// This program is free software; you can redistribute it and/or modify it

// under the terms of the GNU General Public License as published by the Free

// Software Foundation; either version 2 of the License, or (at your option)

// any later version.

//

// This program is distributed in the hope that it will be useful, but WITHOUT

// ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for

// more details.

//

// You should have received a copy of the GNU General Public License along with

// this program; if not, write to the Free Software Foundation, Inc.,

// 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.

//

// ----------------------------------------------------------------------------

//

//####COPYRIGHTEND####

//===========================================================================