Install target for tcl bindings of a C library?

77 views
Skip to first unread message

Steve Havelka

unread,
Mar 19, 2013, 8:14:51 PM3/19/13
to
Hi all,

I've written a C library with a set of Tcl bindings. Building the
library itself on a variety of platforms has been no problem--I'm using
CMake for the cross-platform build system.

I've used CMake's usual install targets for the library itself, and
CMake will put those into the system library path (e.g. /usr/local/lib).
I'm also using CMake to generate a pkgIndex.tcl file for the library.

Something I've never been sure of, though, where should I have the
pkgIndex and .so file for the bindings installed? Is there a generic
install location where I could reliably place these two, so that any tcl
script on the system could package require the module?

Thanks much,

Steve

Harald Oehlmann

unread,
Mar 20, 2013, 3:23:12 AM3/20/13
to
Twylite already proposed to use CMake for TCL Windows build. See
comments on:
http://wiki.tcl.tk/20966

TCL has the TEA build system which is not CMAKE based.

When the TCL interpreter is build, there is a shell script created
maned "tclConfig.sh" and placed in the library path (/usr/local/lib64
on my Centos 64 bit).

Each extension sources this script on the configure command and gives
all build and install information.

You might look to this file and find out how to integrate it into
CMAKE.

-Harald

ssgrif...@gmail.com

unread,
Mar 20, 2013, 10:40:03 AM3/20/13
to
>
> I'm also using CMake to generate a pkgIndex.tcl file for the library.
>

Sorry to highjack the thread but does this mean you are using CMake to build your extension? I'd be interested in looking at that if possible because all of our other projects use CMake except for tcl extensions. Investigating CMake for tcl extensions is on my todo list.

Don Porter

unread,
Mar 20, 2013, 1:08:32 PM3/20/13
to
On 03/19/2013 08:14 PM, Steve Havelka wrote:
> I've written a C library with a set of Tcl bindings. Building the
> library itself on a variety of platforms has been no problem--I'm using
> CMake for the cross-platform build system.
>
> I've used CMake's usual install targets for the library itself, and
> CMake will put those into the system library path (e.g. /usr/local/lib).

Is that library suitable for passing to Tcl's [load] command?

Is it installed in /usr/local/lib for a reason? That is, is there some
use of the library other than as a Tcl package which needs it to be in
that location? Perhaps a runtime loader wants to find it there?

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

Steve Havelka

unread,
Mar 20, 2013, 5:46:57 PM3/20/13
to
Hi, and no worries. I am using CMake and I'd be happy to share how I
did it. You can see the sources for the Tcl bindings for my library here:

http://www.ariesengine.com/cgi-bin/fossil/dir?ci=8ed6c57322d5e61f&name=bindings/tcl

Feel free to email me if the CMakeLists.txt files don't make sense, or
if you have any other questions.

thanks,

Steve

Steve Havelka

unread,
Mar 20, 2013, 6:04:10 PM3/20/13
to
On 03/20/2013 10:08 AM, Don Porter wrote:
> On 03/19/2013 08:14 PM, Steve Havelka wrote:
>> I've written a C library with a set of Tcl bindings. Building the
>> library itself on a variety of platforms has been no problem--I'm
>> using CMake for the cross-platform build system.
>>
>> I've used CMake's usual install targets for the library itself,
>> and CMake will put those into the system library path (e.g.
>> /usr/local/lib).
>
> Is that library suitable for passing to Tcl's [load] command?
>
> Is it installed in /usr/local/lib for a reason? That is, is there
> some use of the library other than as a Tcl package which needs it to
> be in that location? Perhaps a runtime loader wants to find it
> there?
>


Hi Don,

Thanks for giving me an opportunity to clarify the situation.

My code comes in two parts: the library itself (an .so file), and then
a separate .so for each language's bindings. Right now, only Tcl and
Lua have .so files for their bindings--the other languages I've written
binding layers for (i.e. Vala and FreePascal) just link directly against
the library itself.

So the build process for making my library usable from Tcl looks
something like this:

1) Build the library (cmake, make, make install). This drops the
library .so into /usr/local/lib, or wherever you want to put it.

2) Go to the /bindings/tcl/ folder and run cmake and make. This gives
you another .so (and this is the .so usable by [load]) and a
pkgIndex.tcl file, which up to now I've just left in the output
directory with a note to the user to put this where they put their other
Tcl libraries.

It's this last part, where the user has to put those files somewhere by
hand, that I'd like to automate, if possible.


Thanks,
Steve

Twylite

unread,
Mar 27, 2013, 3:26:21 PM3/27/13
to
Hi,

On Wednesday, 20 March 2013 09:23:12 UTC+2, Harald Oehlmann wrote:
> Twylite already proposed to use CMake for TCL Windows build. See

There is some discussion on using CMake with Tcl on the wiki: http://wiki.tcl.tk/21227 .

My COFFEE project (http://dev.crypt.co.za/coffee/) focuses on building Tcl and extensions for Windows, as an alternative to the MSVC Makefiles. It has CMake build files for Tcl 8.6 (builds trunk as at 2012/12/07), Thread, Itcl, Tdbc, and Tk.

I don't know how suitable COFFEE is as a basis for building extensions on multiple platforms. Clifford Yapp has also been working with CMake, and pointed me at https://github.com/starseeker/tcltk for cross-platform build files.

Regards,
Twylite

Steve Havelka

unread,
Mar 27, 2013, 11:19:03 PM3/27/13
to
Hi Twylite,

I'll take a look at the COFFEE project, too.

I've actually come up with sort of a solution to my original problem, of
determining the Tcl package path... I'm not sure if it's the best one
within the confines of CMake, but it seems to work.

What I do is have CMake write out a one-line Tcl script, a script that
just that prints $tcl_pkgPath, which I then capture back into a CMake
variable.

The code for it is here:

http://stevehavelka.com/cgi-bin/ariesengine/artifact/a8eda706a4593ef55184743d996420b6d9ca59f3


thanks,

Steve

Reply all
Reply to author
Forward
0 new messages