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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
4 hours 21 min ago
- seo services in india
8 hours 52 min ago
- For KDE install kio-mtp
8 hours 53 min ago
- Evernote is much more...
10 hours 53 min ago
- Reply to comment | Linux Journal
19 hours 38 min ago
- Dynamic DNS
20 hours 12 min ago
- Reply to comment | Linux Journal
21 hours 11 min ago
- Reply to comment | Linux Journal
22 hours 1 min ago
- Not free anymore
1 day 2 hours ago
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?