otcl, ns/nam (Re: Pending Packages List, 2003-10-21)

[Harold L Hunt II <huntharo at msu dot edu>]

> ITP: ns
> Description: The Network Simulator - ns-2
>    Proposer: Harold L Hunt II
>         ITP: mailto:cygwin-apps-get.11748@cygwin.com
>        Also: nam  [The Network Animator - Nam]
>      Status: ITP posted.
>    HOLD-UPS: Not enough votes (need 3). No package, nothing to review!
>
>
> ITP: otcl
> Description: OTcl, short for MIT Object Tcl, is an extension to Tcl/Tk for ...
>    Proposer: Harold L Hunt II
>         ITP: mailto:cygwin-apps-get.11748@cygwin.com
>        Also: tclcl  [TclCL (Tcl with classes) is a Tcl/C++ interface used by Mash, vic, vat, ...]
>      Status: ITP posted.
>    HOLD-UPS: Not enough votes (need 3). No package, nothing to review!

otcl is turning out to be a nightmare.  It isn't libtoolized, it uses 
ridiculous hard-coded checks, for example for libXext.a (we use 
libXext.dll.a), and it requires source files from tcl in order to be 
built.  It also can't be built in a directory other than the source 
directory (though I usually use lndir for packages that are broken in 
this way).

I am a little leary of distributing it as an independent package.  Do we 
ever do static builds of libraries that are in bad shape and only needed 
by one or two clients?  If so, should I skip otcl and just build ns/nam 
against a static otcl that is not distributed?

Ugh... you would think that a library with less than 100 KiB of source 
would take less time to package than say, lesstif, but you would be wrong :)


I would appreciate any pointers,

Harold