At Sat, 24 Nov 2018 11:33:52 -0800 (PST) jemptymethod <
jempty...@gmail.com> wrote:
>
> On Saturday, November 24, 2018 at 10:50:37 AM UTC-6, Robert Heller wrote:
> >=20
> > Normally, you don't actually need the Tcl *source* tree at all, assuming =
> you=20
> > have a built and installed version of Tcl, with the development files=20
> > (headers, link libraries, etc.). Unless for some reason you want to buil=
> d=20
> > Tcl/Tk from source yourself. Binary distributions are available for just=
> =20
> > about every O/S. ActiveState has binaries for MS-Windows, MacPorts for=
> =20
> > MacOSX, and all major Linux distros have packages for Tcl.
> >=20
> > For CentOS/RHEL type distros (RPM-based), you need tcl and tcl-devel, for
> > Debian-flavored distros (deb-based, eg Ubuntu), you need tcl, libtcl, and
> > tcl-dev. The three files you must have are tcl.h, tclConfig.sh, and
> > libtclstub<mumble>.a. tclConfig.sh contains the info (CFLAGS and LDFLAGS,
> > etc.) needed for compiling a C or C++ coded extension for Tcl -- it conta=
> ins
> > the location of tcl.h and libtclstub*.a, along with the compiler flags to
> > compile and link an extension. You should use a Makefile (preferably usin=
> g
> > autoconf & friends with a Makefile.in &
configure.ac). Oh, you will need =
> the C=20
> > (and C++) compiler, binutils (assembler, linker), and -dev[el] libraries.
> >=20
> > For MacOSX, you need XCode (provides the compiler(s), binutils, etc.) and
> > MacPorts (various libraries and utilities), which gives you the same sort=
> of
> > build environment as Linux.
> >=20
> > MS-Windows is a whole other can of worms.
> >=20
> > > =
> =20
> >=20
> > --=20
> > Robert Heller
>
> I very much appreciate the response. I installed the "complete" ActiveTcl =
> distro as opposed to the "typical", and it did indeed include the developme=
> nt files. I know you said Windows is a whole other can of worms (and thou=
> gh that may be the primary platform I target, I could also set up an Ubuntu=
> VM for the time being) , but I found tcl.h in the /include dir and tclConf=
> ig.sh and tclstub86.lib in /lib ... might the latter be the equivalent of t=
> he libtclstub*.a that you mention?
When I build for a MS-Windows target I do it using a cross-development
environment (mingw32 under Ubuntu). The build environment works like a
UNIX-style build, but uses cross-build tools (compiler, assembler, etc.) and
cross-built libraries. I don't have a machine running MS-Windows.
Yes. MS-Windows's static link libraries are ".lib", where in UNIX/Linux they
are ".a".
There should also be a tclConfig.sh file (or maybe tclConfig.bat under
MS-Windows), probably in /lib. At the very least this will have the compiler
options (CFLAGS) and the linker options (LDFLAGS).
>
> In any case one of my first questions still stands; when I compile would I =
> need to specify *both* the /include and /lib directories with the the compi=
> ler's -Idir option, or just one of them or the other. As for Make "&friend=
> s" as you put it, could I temporarily put that off in order to try to quick=
> ly stand up something on my system. I think I have a book on this somewher=
> e so apparently some time in the past I intended to take this dive.
The *compiler* needs to know where tcl.h is (-I/include). The *linker* needs to
know where tclstub86.lib is (-L/lib, -ltclstub86 options or something like
that). Be sure to include -DUSE_TCL_STUBS to make sure the "stub" interface is
used when compiling.
>
> I don't know if it helps, but my use case is actually to develop bindings t=
> o part of another existing library. Maybe an easy first step will be to ma=
> ke sure I can access that library via C code.
And if the existing has a handly .h file for its API, you can use SWIG to
generate the Tcl interface code. It is pretty close to a "hands off" process,
unless there are things in the existing library's header files that need
special handling.
>
> Thanks in advance for any continued guidance you might provide....George
>