[ECOS] The John's Ousterhout Tcl 6.7 under eCos

[Sergei Gavrikov]

On Wed, 9 Aug 2006, Bart Veer wrote:

>>>>>> "Sergei" == Sergei Gavrikov <w3sg@SoftHome.net> writes:
>
>    Sergei> I am a bit busy now, but I plan to make such a package in
>    Sergei> the one of my weekends before September. And I would want
>    Sergei> ask you about a suitable place in the eCos repository for
>    Sergei> this package. I think what in future somebody can start
>    Sergei> same work porting another version of Tcl for eCos. It
>    Sergei> seems, it will be the best if those Tcl packages will
>    Sergei> occupy a general branch, the services/tcl. So, I plan to
>    Sergei> place the first Tcl 6.7 package under services/tcl/tcl6.7
>    Sergei> branch. Well, I think folk would be to choose one of the
>    Sergei> Tcl packages by Tcl's version (no eCos package version),
>    Sergei> for example
>
> It should probably go into languages/tcl rather than services/tcl.
> There is a tendency to stick anything new into services/ which will
> cause that part of the directory hierarchy to become overpopulated
> eventually. If another part of the hierarchy like languages/ is
> appropriate, that is preferable. languages/tcl can then contain
> subdirectories tcl6.7, tcl7.4, jim, etc. In the medium/long term I
> suspect jim will be the preferred interpreter. Even 7.4 is ancient,
> but 8.0 onwards are not really appropriate for most eCos systems
> because the bytecode compiler/interpreter will need too much memory.
>
>    Sergei>  	ecosconfig add libtcl6.7
>    Sergei>  	ecosconfig add libtcl7.4
>
> No need for the lib, just "ecosconfig add tcl6.7".
>
>    Sergei> or even choose a whole template, like
>
>    Sergei>  	ecosconfig new pid tcl6.7
>
> I do not see any need for a new template since adding Tcl to an
> existing configuration will be straightforward. Adding new templates
> should be avoided because having too many templates to choose from
> makes life confusing for novice users.
>
> Bart

Thank you for your detailed comment. I agree with you by all points. In
these days I was planning to use the languages branch too, but they
pointed me on the services directory. So, I seemed what the languages
directory denied itself to new visitors.

I see what the Jim is perfect choice for the small memory footprint
systems. Jim is the fast and small interpreter. If it would have full
featured the Tcl `format', and Tcl 8.0 `binary format/scan' procs, and
even more, folk around the embedded world would be very happy. But, I
hope it will.

RFC: Bart, I desire to know your point on the CDL build rule to archive
the Tcl's stuffs. Should it be either a usual eCos libextras.a archive
or the separate archive libtcl6.7.a? As I understand in last case the
user's makefile(s) should be more complex.

Thanks,

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss