I have a couple tcl interpreters on my system and i'd like to pick which one the C API for tcl uses. Is there a way to do this?
Thanks!
The C api doesn't pick the interpreter, you pick the C api corresponding to the interpreter you wish to use, by changing the include and link paths.
You pass the interpreter to the C API, having first created it with Tcl_CreateInterp. For example Tcl_Eval's interface is:
int Tcl_Eval(Tcl_Interp *interp, const char *script)
Generally speaking, when running a Tcl program you pick the API by selecting the interpreter. You can do this explicitly by naming the interpreter program as exactly as you choose:
bash$ /my/special/place/bin/tclsh8.6 thescript.tcl ...
Or you can put this trick with the standard env program at the start your executable Tcl script and rely on the OS to process your PATH environment to select a suitable one:
#!/usr/bin/env tclsh8.6
It's standard to install Tcl interpreters with the version in their names so that you can easily have different versions on the system.
When creating a C program that uses the Tcl library, you select the headers and libraries (which are usually best regarded as a matched set) by setting your include and library path. Unix compilers usually use -I and -L options to do that respectively; a script (tclConfig.sh) is typically also installed to make getting those options right easier. Note that while Tcl's libraries are usually versioned in their names, Tcl's header files are not; if you install multiple versions of the headers into the same place, only the most recent version will be usable.
It's possible to use standard options to configure when building Tcl to make everything split up better.
Related
I am trying to create a program where the user can add different path regex-s so that a specific set of operations on the files that match the regex.
I tried using opendir() of the dirent.h header file but soon realized that it does not use the concept of regex.
The dir command I am trying to emulate is
dir [regex] /b
I need the output in a (char) buffer**. Piping the output could be a solution but I am looking for a more efficient way to do it.
Is there any predefined function in the standard (C90) library or will we have to create our own implementation?
C does not know about directories. They are operating system specific, usually provided by your OS kernel (look however inside GNU Hurd as an exception, and into unikernels). Read the C11 standard n1570 and forget, in 2020, about the obsolete C89 standard and TurboC. Consider trying some Linux distribution (such as Ubuntu or Debian or others). Most of them provide GCC or Clang (or the non-optimizing TinyCC compiler) and are very developer-friendly. My recommendation: use GCC as gcc -Wall -Wextra -g. Choose a good enough built automation tool (maybe GNU make) with an appropriate source-code editor (such as GNU emacs or vim or geany or others). Learn how to debug small programs and use the GDB debugger and the git version control tool.
POSIX does know about directories (it is an API specification written in English, also defining regex(3)). See here, and read the Linux man pages. And also the WinAPI.
On Linux, see mkdir(2), chdir(2), readdir(3), getcwd(3), unlink(2), stat(2), open(2), nftw(3), path_resolution(7) etc etc; you could want to study the source code of a Linux kernel and of some common C library for it, such as GNU glibc or musl-libc. Budget for that several months full time of your efforts. They are open source, so with some conditions you are allowed to study, improve and reuse their source code. See also http://linuxfromscratch.org/
Notice also popen. You probably don't want to use it and would prefer using more primitive system calls (see syscalls(2) for their list on Linux). You could use a library like Glib (from GTK).
Remember that C programs (of the freestanding kind) could run on the bare metal (e.g. Arduino). In those cases, speaking of directories does not make any sense. See also osdev.org for more, and observe that the Linux kernel is written in C (with a tiny amount of assembler code).
GrassHopper was an OS written mostly in C without any files or directories. See also old discussions archived on tunes.org and tccboot.
Use the function findfirst to start querying a directory and then findnext to iterate. The functions find all files in one directory matching a given pattern, so you possibly need to append \*.* to your directory name to list all files in that directory.
Refer to the Turbo C documentation for details.
Hello I was wondering if there was a C framework for windows? Like if someone wanted to run a C program on Windows would they have to download C?
The C programming language does require some runtime support libraries; however, these are included in all major OS distributions (both Windows and UNIX). So, you just need to compile a C program targetting the desired CPU instruction set (e.g. "x86" for Intel chips) and distribute the compiled output. You don't need the user to install a separate set of libraries.
That being said, most programs of a sufficiently large size do rely on third party libraries and data files to work. This is why there are installer applications that copy over not just a single file but an entire directory containing the executable as well as the various libraries and associated files that are required to make that program work.
I'd like to provide a program, for example a Python script, that can be run on platforms including Linux, Mac, and Windows. I want the program to read the content of a few files in the directory, and create a new file in that directory based on the content. Specifically, I want the program to find file1.txt and file2.txt, and create a new file file3.txt which is a concatenation of the first two files.
I might provide a Python script to a Linux user, and the user can run
python script.py
However, Windows does not have Python. What other choices of programs do I have that will allow it to be run on these platforms, without the user having to install anything extra?
You could use C++, but then you'd have to compile for each platform, which is sometimes more work than you'd like.
Most systems have some form of Java installed already, which could work.
Python runs on Windows, Mac and Linux, the user would just need to install it.
I am not aware of anything that will run on all OSes without any extra work. However, Java may be a good choice as it is commonly installed. You could use C++ but you would have to compile it on each machine you would like it to work on (Windows, Mac, Linux) you would also have to make sure you don't use any library that does not transfer to the other OSes.
If I just want to use the gsl_histogram.h library from Gnu Scientific Library (GSL), can I copy it from an existing machine (Mac OS Snow Leopard) that has GSL installed to a different machine (Linux CentOS 5.7) that doesn't have GSL installed, and just use an #include <gls_histogram.h> statement in my c program? Would this work?
Or, do I have to go through the full install of GSL on the Linux box, even though I only need this one library?
Just copying a header gsl_histogram.h is not enough. Header states merely the interface that is exposed by this library. You would need to copy also binaries like *.so and *.a files, but it's hard to tell which ones to copy. So I think the you'd better just install it on your machine. It's pretty easy, just use this tutorial to find and install GSL package.
So there are surely a lot of libraries out there. However the particular one is Gnuplot. Using it you even do not need to compile the code, however you do need to read a bit of documentation. But luckily there is already a question about how to draw a histogram with Gnuplot on Stackoverflow: Histogram using gnuplot? It worth noting that Gnuplot is actually very powerful tool, so invested time into reading its documentation will certainly pay off.
You cannot copy libraries from OS and expect them to work unchanged.
OS X uses the Mach-O object file format while modern Linux systems use the ELF object file format. The usual ld.so(8) linker/loader will not know how to load the Mach-O format object files for your executable to execute. So you would need the Apple-provided ld.so(8) -- or whatever they call their loader. (It's been a while.)
Furthermore, the object files from OS X will be linked against the Apple-supplied libc, and require the corresponding symbols from the Apple-supplied library. You would also need to provide the Apple-provided libc on the Linux system. This C library would try to make system calls using the OS X system call numbers and calling conventions. I guarantee the system call numbers have changed and almost certainly calling conventions are different.
While the Linux kernel's binfmt_misc generic object loader can be used to teach the kernel how to load different object file formats, and the kernel's personality(2) system call can be used to select between different calling conventions, system call numbers, and so on, the amount of work required to make this work is nothing short of immense: the WINE Project has been working on exactly this issue (but with the Windows format COFF and supporting libraries) since 1993.
It would be easier to run:
apt-get install libgs0-dev
or whatever the equivalent is on your distribution of choice. If your distribution does not make it easily available, it would still be easier to compile and install the library by hand rather than try to make the OS X version work.
I am in a big problem ..i have compiled my c files using linux make file in Linux OS.
I want to compile the same files in Windows using the same make file by command prompt. For that i have nmake utility and Cygwin utility too.
I have done that successfully with simple programs with simple make file ..
But it is not possible to compile when i was using the complex C files with complex make file.
I have changed the '/' in linux make file to '\' in windows? Anyother changes?
I want to know 'Is there any special make file formats in windows?'
also the difference between them..
I am really in need of that...
Unfortunately, nmake was only loosly inspired by make, and they didn't get many important things right. By far the easiest thing to do is to start by having the same flavor of make on both platforms.
On linux, Gnu make is the default and best option.
On Windows, there are several sources for Gnu make, with some quirks to choose among. Personally, I mostly use the native win32 build of Gnu make from the GnuWin32 project. You might want to poke around at the rest of the project's packages because some of the others will be useful to have as well.
Alternative sources are Cygwin and MinGW32/MSYS.
Cygwin is a credible attempt at providing a *nix compatibility environment on top of the Windows kernel. It consists of a DLL that exports a huge percentage of *nix (especially POSIX) system calls implemented via the Windows API. That DLL also has its own idea about disk mounts and prefers *nix-style path names. The DLL itself is licensed GPL (although a commercial-use license is available for a fee), and programs built in the Cygwin environment require it by default, so that can be a factor to consider. Another factor is that Cygwin is not friendly to normal Windows users, so development projects based on it usually end up difficult for non-unix users to deal with. For a cross-platform developer, however, Cygwin can be really useful as it gets you all of the usual suspect utility programs required by your Makefile, and it includes the MinGW32 native Windows targeted GCC as well as a GCC targeting the Cygwin environment.
MinGW32 is a porting project that did a really good job of porting the GCC compilers to run as native Windows executables. If used along with the header files they supply, it is possible to use nearly all of the Windows API via a C runtime DLL that ships with modern Windows installations.
MSYS is a lightweight fork of Cygwin that contains a minimal set of utilities (starting with a *nix shell) that are usually assumed to exist by a typical *nix Makefile. Unlike Cygwin, MSYS is configured such that the default target is the native Windows API.
What I'm trying to hint at here, and probably should just state flat out, is that your compatibility issues don't end with the dialect of make you use.
The Makefile language itself is highly dependent on the command shell available, and most serious project Makefiles end up using many of the *nix the core utilities such as cp and rm.
I would strongly recommend starting with the GnuWin32 build of make, and also installing MinGW32 and MSYS. It is then relatively easy to write a Makefile that works under both MSYS and linux, and needs only a small amount of platform-specific logic.
You should consider CMake for cross-platform make but your real problem is you shouldn't have to change the '/' to '\'. If you run under cygwin or msys (recommended) this should be handled for you.
NMake is a windows tool and will parse only windows-style paths, i.e. paths with drive letters and backslashes. Therefore you should use GNU Make installed with cygwin.
nmake should read your makefiles okay, the differences are generally between versions of make rather than OSs.
The big question is what your target platform actually is, are you trying to make this code operate in Windows natively or are you looking to run it under Cygwin?
Use gnumake on both platforms. I do. I haven't touched Visual C in years.
nmake got it's own format rather than windows itself, so makefile format is related to make tool rather than os. For simple things format is similar for g(nu)make and nmake, as people suggested before consider using gmake only.