Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

cross-platform tcl c extension questions

3 views
Skip to first unread message

chewie54

unread,
Nov 14, 2007, 10:20:56 PM11/14/07
to
Hi All,

When writing a tcl c extension for that needs to be compiled for
Windows, Linux, and the Mac,
what cross-platform differences need to be accounted for? Are there
functions in the tcl api to deal with the differences? For
example, byte ordering, how is that controlled?

Thanks in advance,

tom.rmadilo

unread,
Nov 14, 2007, 10:55:21 PM11/14/07
to

If you are just using the Tcl C API, you probably are not going to run
into any problems. If you extend your application into areas not
covered by this API, then you will need to write an abstraction layer.
AOLserver offers a good example (particularly for networking/
pthreads), and there are others.

Torsten Reincke

unread,
Nov 15, 2007, 4:02:00 AM11/15/07
to

> When writing a tcl c extension for that needs to be compiled for
> Windows, Linux, and the Mac,

... you should try to use the TEA build system, that makes compiling
on different platforms easy: http://wiki.tcl.tk/327

> what cross-platform differences need to be accounted for? Are there
> functions in the tcl api to deal with the differences?

The public Tcl C API (Tcl_... functions) is designed to hide platform
specific differences so it works on all platforms.

> example, byte ordering, how is that controlled?

If you read text files for example, you get back utf-8 characters from
Tcl, that are correct regardless of the platform. Only if you use
binary encoding (ByteArrayObj), there will be no byte reordering or
interpretation for that matter, because binary data are treated as
having no implicit meaning (citing tha man page for
Tcl_NewByteArrayObj.

Torsten

Bezoar

unread,
Nov 17, 2007, 6:50:19 PM11/17/07
to

I would start by looking at tcl itself and seeing the how the
configure script changes the makefiles and the defines for the
compile.
Incorporate the # defines in your own code and you should have
reasonably portable code.

Carl

0 new messages