What other files are necessary to create Tcl extension

[jemptymethod]

I am completely new to writing Tcl extensions (and almost completely new to writing C code), and I have what is probably an incredibly elementary question. Both in an edition of Brent Welch's book dating to 2000, and on the wiki (https://wiki.tcl-lang.org/page/Hello+World+as+a+C+extension), the first line of C code is "#include <tcl.h>", including the header file, this much I understand.

But what *other* files are then necessary for the compilation of the extension? Just the other files in the "generic" directory (I've downloaded the source)? Or apparently according to the README, additionally the files in the directory corresponding to the platform, macosx, unix or win. Does it need files from any of the other directories? Here they all are at the top level at least:

+-- compat
+-- doc
+-- generic
+-- library
+-- libtommath
+-- macosx
+-- pkgs
+-- tests
+-- tools
+-- unix
+-- win

Presuming the compiler is configured to pick up tcl.h from the "generic" directory using the compiler's -Idir option, will it then pick up whatever is necessary in adjacent directories, or do those need to be specified using --Idir as well?

Sorry if this is old hat for some of you. Also sorry if this is documented somewhere. Any pointers are appreciated, and maybe I can contribute back to the wiki as I become successful.

Thanks in advance....George

[Robert Heller]

At Sat, 24 Nov 2018 08:00:38 -0800 (PST) jemptymethod <jempty...@gmail.com> wrote:

>
> I am completely new to writing Tcl extensions (and almost completely new to=
> writing C code), and I have what is probably an incredibly elementary ques=
> tion. Both in an edition of Brent Welch's book dating to 2000, and on the =
> wiki (https://wiki.tcl-lang.org/page/Hello+World+as+a+C+extension), the fir=
> st line of C code is "#include <tcl.h>", including the header file, this mu=
> ch I understand.
>
> But what *other* files are then necessary for the compilation of the extens=
> ion? Just the other files in the "generic" directory (I've downloaded the =
> source)? Or apparently according to the README, additionally the files in =
> the directory corresponding to the platform, macosx, unix or win. Does it =
> need files from any of the other directories? Here they all are at the top=

> level at least:
>
> +-- compat
> +-- doc
> +-- generic
> +-- library
> +-- libtommath
> +-- macosx
> +-- pkgs
> +-- tests
> +-- tools
> +-- unix
> +-- win
>

> Presuming the compiler is configured to pick up tcl.h from the "generic" di=
> rectory using the compiler's -Idir option, will it then pick up whatever is=
> necessary in adjacent directories, or do those need to be specified using =
> --Idir as well?
>
> Sorry if this is old hat for some of you. Also sorry if this is documented=
> somewhere. Any pointers are appreciated, and maybe I can contribute back =

> to the wiki as I become successful.
>
> Thanks in advance....George

Normally, you don't actually need the Tcl *source* tree at all, assuming you
have a built and installed version of Tcl, with the development files
(headers, link libraries, etc.). Unless for some reason you want to build
Tcl/Tk from source yourself. Binary distributions are available for just
about every O/S. ActiveState has binaries for MS-Windows, MacPorts for
MacOSX, and all major Linux distros have packages for Tcl.

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 contains
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 using
autoconf & friends with a Makefile.in & configure.ac). Oh, you will need the C
(and C++) compiler, binutils (assembler, linker), and -dev[el] libraries.

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.

MS-Windows is a whole other can of worms.

>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[jemptymethod]

On Saturday, November 24, 2018 at 10:50:37 AM UTC-6, Robert Heller wrote:
>
> Normally, you don't actually need the Tcl *source* tree at all, assuming you
> have a built and installed version of Tcl, with the development files
> (headers, link libraries, etc.). Unless for some reason you want to build
> Tcl/Tk from source yourself. Binary distributions are available for just
> about every O/S. ActiveState has binaries for MS-Windows, MacPorts for
> MacOSX, and all major Linux distros have packages for Tcl.
>
> 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 contains
> 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 using
> autoconf & friends with a Makefile.in & configure.ac). Oh, you will need the C
> (and C++) compiler, binutils (assembler, linker), and -dev[el] libraries.
>
> 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.
>
> MS-Windows is a whole other can of worms.
>
> >
>
> --
> 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 development files. I know you said Windows is a whole other can of worms (and though 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 tclConfig.sh and tclstub86.lib in /lib ... might the latter be the equivalent of the libtclstub*.a that you mention?

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 compiler's -Idir option, or just one of them or the other. As for Make "&friends" as you put it, could I temporarily put that off in order to try to quickly stand up something on my system. I think I have a book on this somewhere so apparently some time in the past I intended to take this dive.

I don't know if it helps, but my use case is actually to develop bindings to part of another existing library. Maybe an easy first step will be to make sure I can access that library via C code.

Thanks in advance for any continued guidance you might provide....George

[Rich]

jemptymethod <jempty...@gmail.com> wrote:
> 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 compiler's -Idir option, or just one of them or the other.

Try compiling a very basic *.c file without any special flags (if you
want, search the wiki for a very basic *.c file to use). If you get
errors about not finding tcl.h or the libs, then you know you need the
flags. If you can compile an executable without the flags, then you
know your system does not need them (i.e., the *.h and *.so files are
where the compiler looks by default).

> As for Make "&friends" as you put it, could I temporarily put that
> off in order to try to quickly stand up something on my system. I
> think I have a book on this somewhere so apparently some time in the
> past I intended to take this dive.

Basic make usage is actually relatively simple. You specify a target
and the items upon which the target depends, then describe how to
create the target from the dependencies.

The advantage you get from a Makefile is you don't have to remember all
the flags (if you do need flags). Just just have to put them in the
Makefile once, then they get remembered for you.

[Robert Heller]

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
>

[jemptymethod]

Robert and Rich, thanks for your responses.

I know I am probably biting off more than I can chew, but I am trying to break it into baby steps. I'll probably refer back to the answers above as a reference as I (hopefully) progress.

Yesterday evening I needlessly grappled with trying to get Code Blocks to work with Visual Studio build tools, see https://stackoverflow.com/questions/53464002/cannot-open-file-libcmt-lib-when-using-code-blocks-with-vs-build-tools if interested

So I'm either going to work directly within Visual Studio IDE for Windows, or go the cross-compile route from Ubuntu as mentioned.

[Robert Heller]

If you go with the cross-build route, have a look at MXE (pkg.mxe.cc).