ICMAKE Part 1
Icmake was developed initially as a make-tool to be used under MS-DOS. Although make-utilities under MS-DOS exist, we tended not to use these utilities for a two main reasons:
Since our primary language is C (C++), we considered the grammar of the make utilities awkward.
In a program development cycle in which sources are compiled, included in a library, which is then linked to a main object module we experienced problems in setting up the correct dependencies between files.
Once icmake was developed, it was soon thereafter ported to UNIX, where it now not only serves as our make-utility of choice. However, by now it also serves as a utility with which we find it easy to write shell-scripts.
Currently icmake has been ported to several UNIX platforms, such as LINUX, SCO-UNIX, HP-UX, and SunOS. Icmake, therefore, reflects almost perfectly the transition from DOS to UNIX we experienced ourselves: developed initially under MS-DOS, it has now become primarily a UNIX tool. But then, we used the `tools of the trade', already under MS-DOS: both bison and flex were used for the construction of the icmake compiler icm-comp. The first version of icmake was available after some nine days, including the decisions we had to take about what form it should take. Since we were also working with some UNIX platforms (SunOS and AIX) by that time, the `porting daemon' started to influence our implementation descisions as well. The first port of icmake to a unix operatingsystem took only a few days, which time was mainly invested in porting some specific MS-DOS functions to an acceptable UNIX form.
In this article we describe icmake from the point of view of its users. The organization of the software, the grammar of icmake files, icmake-scripts and -to start with-the way to obtain icmake is described in the remainder of this article. At the end some illustrative examples of icmake-scripts are given.
Icmake can be obtained by anonymous ftp from the site beatrix.icce.rug.nl, where it is found in the directory pub/unix.
The package consists of an archive, usually in the form icmake-X.XX.tar.gz, where the current version of icmake is denoted by X.XX. This archive contains a tarred and gzipped directory structure, in which the source files for icmake (and the executable programs for MS-DOS) can be found. Also at beatrix.icce.rug.nl the file icmake.doc can be be found, which is a guide to the installation of icmake. This latter file is especially useful for UNIX installations.
Alternatively, icmake can also be found at tsx-11.mit.edu, where it is part of the Linux Operating System distribution. At tsx-11.mit.edu the icmake-files are usually located in pub/linux/sources/usr.bin.
Apart from the source-distribution and the installation guide there is a icmake.dvi file available at beatrix.icce.rug.nl describing icmake in somewhat more detail than is possible in this article. Also, a postscript version (icmake.ps) of the documentation is available.
Icmake consists of five programs. One program is a nitor program, monitoring the construction and execution of an icmake file. The monitor program may call an icmake preprocessor, an icmake compiler and an icmake executor. A fifth program is the icmake unassembler, showing the code generated by the icmake compiler in a human-readable form.
The programs can be divided in two categories: programs of which the ordinary user of icmake must be aware (the top-level programs) and programs which are called internally by icmake (the nested-level programs). The top-level programs are the icmake-monitor program and the icmake unassembler. Normally, only the monitor program is started at the command line, but programs of the nested-level are sometimes called explicitly. All icmake programs can be started as stand-alone programs.
The normal processing of an icmake script runs as follows:
An icmake source script is written, containing a description of the tasks to be performed by icmake. This script is very C-like.
The monitor is started, receiving the name of the file containing the icmake source script as its argument.
The monitor program may call the icmake preprocessor and the icmake compiler to convert the source file in a binary file to be processed by the icmake executor.
The icmake executor is started by the monitor. The executor reads the compiled icmake script, executing the instructions found in the compiled script.
Once an icmake-script has beenompiled, the compilation and preprocessing phases are skipped by the monitor program, and the icmake executor is called immediately. In this way icmake monitors its own dependency between the icmake source script and the compiled icmake script.
Each of the programs of the icmake family has a version number. The version numbers consist of a major and a minor number. E.g., in the version number 6.03, the major version is 6 and the minor version is 03. The programs can only communicate when the major version numbers of all icmake programs are equal. So a working set of programs must all have the same major version number. The minor number is used to indicate small changes in the separate programs.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|Fancy Tricks for Changing Numeric Base||May 29, 2016|
|Working with Command Arguments||May 28, 2016|
|Secure Desktops with Qubes: Installation||May 28, 2016|
|CentOS 6.8 Released||May 27, 2016|
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
- Tips for Optimizing Linux Memory Usage
- Working with Command Arguments
- Secure Desktops with Qubes: Introduction
- Secure Desktops with Qubes: Installation
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- CentOS 6.8 Released
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
- ServersCheck's Thermal Imaging Camera Sensor
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide