Building Projects With Imake
There are various files involved in the Imake build system; most reside in the Imake configuration directory. Though only one file, Imakefile, is really important to simple uses of Imake, these descriptions are included as a sort of a road map to more in-depth understanding of how Imake works.
Imakefile is the file used to generate a Makefile. This file contains your project specific information.
Makefile is the final output file. There are many references to help you understand the contents of the Makefile. The easiest to obtain is probably the GNU Info pages on GNU make, which come with the GNU make distribution. See the References section for specifics on information available about make.
Imake.tmpl is a generic template used to fill in information not provided by the Imakefile. Most template files are created for large projects that need to customize Imake beyond what is possible through the Imakefile. (The FVWM source as an example.)
Imake.rules and other .rules files hold the C preprocessor “defines” that make up the bulk of the Imake rules. Things like SimpleProgramTarget() and DependTarget() are defined in this file.
.cf files contain system specific configuration information. Imake.cf is the file that “chooses” the proper platform-specific .cf file.
Once you've written a basic Imakefile, it's time to put Imake to work. Fortunately, the difficult part is over. Just type the following two commands:
xmkmf -a make
If you've written your Imakefile properly, your project will build with no problems.
xmkmf is a Bourne shell script that wraps up the imake command. It calls imake with convenient default arguments and does some cleanup, such as copying the old Makefile to Makefile.bak. This program generates the Makefile from your Imakefile.
imake is a program that you almost never need to run by hand. It's the program that handles the brunt of running the C preprocessor, as well as some minor tweaking (i.e., XCOMM comments) for compatibility with make.
Without any arguments, xmkmf just saves the old Makefile and runs imake to generate a new Makefile from the Imakefile. If you give xmkmf the -a switch, it runs the following commands in the given order:
make Makefile make includes make depend
See the xmkmf(1) man pages for more details on xmkmf capabilities.
Below is a list of the common make targets contained in an Imake generated Makefile. Precisely which targets end up in your Makefile depend on which rules you used in your Imakefile, of course. A given target always does the same thing regardless of the project. (That is, it will if the Imakefile has been written properly.) In fact, these targets are standard beyond Imake. For example, the GNU Coding Standards specify much the same targets.
all: Build the whole project. Usually the default target. This is the target to which the AllTarget() rule adds a dependency.
clean: Remove buildable files and backup files. Includes all object files, executables, backup Makefiles and files commonly used by editors as backup files (*~).
Makefiles: regenerates all the Makefiles using Imake.
depend: generates the dependences between source (*.c) and header (*.h) files and ensures that all object files that need recompiling are rebuilt.
tags: builds the tags database used by vi and Emacs. The tags database is simply a list of C-language symbols and their location in the source. It allows for quickly and automatically locating function definitions and other such objects. See the man pages for etags(1), ctags(1), vi(1) and the Info documentation that comes with Emacs.
install: installs the final binaries into the main file system. Defaults to a directory under /usr/X11R6/ depending on each type of component. For example, executables go in /bin; man pages go into the proper section directory under /man.
lint: This target isn't particularly useful on Linux systems, since there isn't a commonly used lint program. lint is a program that checks C code for common style problems and other non-syntactic mistakes. The GNU compiler has moved much of the functionality of lint into the compiler, compile your code with the -Wall flag set and you'll have most of lint's functionality. With a lint program installed on the system, you can use this make target to run lint on all the source files of the project.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide