This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: The John's Ousterhout Tcl 6.7 under eCos
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