JuanJuan Xiang | LinkedIn

JuanJuan Xiang | LinkedIn: "Equity Strategist"

nikobrummer

nikobrummer

Another Graduate

http://www.hlt.utdallas.edu/~feiliu/

steve jobs stanford commencement speech 2005

'You've got to find what you love,' Jobs says

http://news.stanford.edu/news/2005/june15/jobs-061505.html

This is the text of the Commencement address by Steve Jobs, CEO of Apple Computer and of Pixar Animation Studios, delivered on June 12, 2005.

I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life. That's it. No big deal. Just three stories.

The first story is about connecting the dots.

I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?

It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.

And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.

It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢ deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:

Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating.

None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, it's likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.

Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

My second story is about love and loss.

I was lucky — I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation — the Macintosh — a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.

I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me — I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.

I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.

During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I returned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.

I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.

My third story is about death.

When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.

Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.

I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now.

This was the closest I've been to facing death, and I hope it's the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:

No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma — which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.

Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.

Stay Hungry. Stay Foolish.

Thank you all very much.

How to install VirtualBox Guest Additions - Tutorial

http://www.dedoimedo.com/computers/virtualbox-guest-addons.html

build binary file in linux[best]

BUILDING FROM TARBALL(*.tar or *.tar.gz) DISTRIBUTIONS:

Installing package (eg. Speex) is as easy as:

 ./configure [--prefix=<install-path>]
 make
 make install

Note that if you are using the code from SVN, you will need to run "autogen.sh"
instead of "configure". (but how to specify install-path?)

./autogen.sh
make
make install

http://cykod.com/blog/post/2010-12-building-a-simple-online-karaoke-site

Building a simple online Karaoke site

TL;DR - We built a online holiday themed sing-a-long site called carolwith.me to play around with recording web audio without a streaming server and synchronizing HTML5 Audio tags with playback. Check out FlashWavRecorder and Read the notes at the bottom for our takeaways.

HowTo write generic Makefiles [Good]

http://www.puxan.com/Computers/Howto-write-generic-Makefiles


HowTo write generic Makefiles
Contents
1 Pattern rule to build objects
2 Main target
3 Generic example
4 See also
5 References

Pattern rule to build objects

The first thing we need to write a generic Makefile is a rule to build object files without having to specify their name. That is to say, we need a pattern rule. This could be written in two different ways, but they both mean the same.
.cpp.o:

or
%.o: %.cpp


Now that we have a pattern rule, we will need to write the actions to be taken, and so we will need the file names. As we don't know them, because the rule is the same for all the cpp files, we are going to use automatic variables. This feature let us access to the current target name and dependencies.

There are many automatic variables but we will only need these two:

$@ Contains the target file name.

$< Contains the first dependency file name.

So a generic rule to compile source files could be as follows:
# Generic rule
%.o: %.cpp
    $(CC) -c $(CC_FLAGS) $< -o $@



Main target

Now that we know how to build the objects, we need to build the executable.  To link executable we need all the object files. So we have to write a rule where the prerequisites are all the object files. To do that we could think of using something like *.o, but remember that object files don't yet exist. So we have to use source code names to obtain the object names. If we had all the sources names in $SOURCES we could do as follows:
OBJECTS = $(SOURCES:.cpp=.o)


To initialize $SOURCES do not use *.cpp, because make won't do what you expect. Make would compile all the sources, but they would all be compiled even if they haven't been modified. Therefore you would be loosing the power of this tool.
To avoid this problem you can initialize $SOURCES like this:
SOURCES = $(wildcard *.cpp)



Generic example

Using the things previously explained we would be able to write a generic make. But notice that we haven't used header files in the dependencies part. Therefore if we modify a header file, make may not recompile all the code that depends on this header. So, after modifying a header file, we should type make clean before executing make.
# Declaration of variables
CC = g++
CC_FLAGS = -w

# File names
EXEC = run
SOURCES = $(wildcard *.cpp)
OBJECTS = $(SOURCES:.cpp=.o)

# Main target
$(EXEC): $(OBJECTS)
    $(CC) $(OBJECTS) -o $(EXEC)

# To obtain object files
%.o: %.cpp
    $(CC) -c $(CC_FLAGS) $< -o $@

# To remove generated files
clean:
    rm -f $(EXEC) $(OBJECTS)


See also

HowTo write simple Makefiles


References

GNU Make user manual

Makefile Tutorial

Makefile Tutorial: "ith this brief introduction to Makefiles, you can create some very sophisticated mechanism for compiling"

Tutorial - Makefile

Tutorial - Makefile

The Makefile

Comments Rules Dependency Lines Shell Lines Macros Macro Modifiers Inference Rules Response Files Makefile Directives

Make reads its instructions from text files. An initialization file is read first, followed by the makefile. The initialization file holds instructions for all “makes” and is used to customize the operation of Make. Make automatically reads the initialization file whenever it starts up. Typically the initialization file is named make.ini and it resides in the directory of make.exe and mkmf.exe. The name and location of the initialization file is discussed in detail on Page .

The makefile has instructions for a specific project. The default name of the makefile is literally makefile, but the name can be specified with a command-line option.

With a few exceptions, the initialization file holds the same kind of information as does a makefile. Both the initialization file and the makefile are composed of the following components: comments,dependency lines, directives, macros, response files, rules and shell lines.

Continued Makefile Lines

Lines in the makefile can be very long. For easier reading a long line can be broken up by putting “\enter” as the last characters of this line and the rest of this (logical) line on the next (physical) line of the makefile. For example:

first_part_of_line second_part_of_line

is the same as:

first_part_of_line \
second_part_of_line

Comments [Top]

The simplest makefile statement is a comment, which is indicated by the comment character “#”. All text from the comment character to the end of the line is ignored. Here is a large comment as might appear in a makefile to describe its contents:

# # Makefile for Opus Make 6.1 # # Compiler: Microsoft C 6.0 # Linker: Microsoft Link 5.10 # 

The comment character could also be used at the end of another makefile statement:

some makefile statement # a comment 

Comments and Continued Makefile Lines

If “\enter” appears on a commented line, the comment acts until the end of the line and the following line is still continued. For example:

line_one \ line_two # more_line_two \ line_three 

is the same as:

line_one line_two line_three 

Rules [Top]

A rule tells Make both when and how to make a file. As an example, suppose your project involves compiling source files main.c and io.c then linking them to produce the executable project.exe. Withholding a detailed explanation for a bit, here is a makefile using Borland C which will manage the task of making project.exe:

The Example Makefile

project.exe : main.obj io.obj  tlink c0s main.obj io.obj, project.exe,, cs /Lf:\bc\lib 

main.obj : main.c  bcc –ms –c main.c 

io.obj : io.c  bcc –ms –c io.c 

This makefile shows three rules, one each for making project.exe, main.obj, and io.obj. The rules as shown above are called explicit rules since they are supplied explicitly in the makefile. Make also has inference rules that generalize the make process. Inference rules are discussed on Page and in the User's Guide on Page .

We will return to and modify this example during the course of this tutorial.

Dependency Lines: When to Build a Target [Top]

The lines with the colon “:” in them are called dependency lines. They determine when the target is to be rebuilt.

To the left of the colon is the target of the dependency. To the right of the colon are the sources [1] needed to make the target. A dependency line says “the target depends on the sources.” For example, the line:

project.exe : main.obj io.obj 

states that project.exe depends on main.obj and io.obj. At run time Make compares the time that project.exe was last changed to the times main.obj and io.obj were last changed. If either source is newer than project.exe, Make rebuilds project.exe. The last-changed time is the target's time as it appears in the file-system directory. This time is also known as the target's timestamp.

The Make Process is Recursive

It is a basic feature of Make that a target's sources are made before the timestamp comparison occurs. The line:

project.exe : main.obj io.obj 

implies “make main.obj and io.obj before comparing their timestamps with project.exe.” In turn:

main.obj : main.c 

says “make main.c before comparing its timestamp with main.obj.” You can see that if main.c is newer than main.obj, main.obj will be rebuilt. Now main.obj will be newer than project.exe, causing project.exe to be rebuilt.

Additional Dependencies

In C and in other programming languages it is possible to include the contents of a file into the file currently being compiled. Since the compiled object depends on the contents of the included file, we add the included file as a source of the object file.

Assume each of main.c and io.c include def.h. We can either change two dependency lines in the makefile:

main.obj : main.c becomes main.obj : main.c def.h io.obj : io.c becomes io.obj : io.c def.h 

or add a new line which lists only the additional dependencies:

main.obj io.obj : def.h 

Notice that there are two targets on the left of the colon. This line means that both main.obj and io.obj depend on def.h. Either of these methods are equivalent. The example makefile now looks like:

project.exe : main.obj io.obj  tlink c0s main.obj io.obj, project.exe,, cs /Lf:\bc\lib 

main.obj : main.c  bcc –ms –c main.c 

io.obj : io.c  bcc –ms –c io.c 

main.obj io.obj : incl.h

Shell Lines: How to Build a Target [Top]

The indented lines that follow each dependency line are called shell lines. Shell lines tell Make how to build the target. For example:

project.exe : main.obj io.obj  tlink c0s main.obj io.obj, project.exe,, cs /Lf:\bc\lib 

tells Make that making project.exe requires running the program tlink to link main.obj and io.obj. This shell line would be run only if main.obj or io.obj was newer than project.exe.

For tlink, c0s is the small model start-up object file and the cs is the small model library. The /Lf:\bc\lib flag tells tlink that the start-up object file and library files can be found in the f:\bc\libdirectory.

A target can have more than one shell line, listed one after the other, such as:

project.exe : main.obj io.obj  echo Linking project.exe  tlink c0s main.obj io.obj, project.exe,, cs /Lf:\bc\lib >tlink.out 

The first line shows that command processor commands can be executed by Make. The second line shows redirection of output, where the output of the tlink program is redirected to the tlink.out file.

After each shell line is executed, Make checks the shell line exit status. By convention, programs return a 0 (zero) exit status if they finish without error and non-zero if there was an error. The first shell line returning a non-zero exit status causes Make to display the message:

OPUS MAKE: Shell line exit status exit_status. Stop. 

This usually means the program being executed failed. Some programs return a non-zero exit status inappropriately and you can have Make ignore the exit status by using a shell-line prefix. Prefixes are characters that appear before the program name and modify the way Make handles the shell line. For example:

project.exe : main.obj io.obj  – tlink c0s main.obj io.obj, project.exe,, cs /Lf:\bc\lib 

The “–” prefix tells Make to ignore the exit status of shell line. If the exit status was non-zero Make would display the message:

OPUS MAKE: Shell line exit status exit_status (ignored) 

See Page for more information on shell lines and shell-line prefixes.

Macros [Top]

The example makefile is reproduced here:

project.exe : main.obj io.obj  tlink c0s main.obj io.obj, project.exe,, cs /Lf:\bc\lib 

main.obj : main.c  bcc –ms –c main.c 

io.obj : io.c  bcc –ms –c io.c 

main.obj io.obj : def.h 

We see that the text “main.obj io.obj” occurs repeatedly. To cut down on the amount of repeated text, we can use a macro definition to assign a symbol to the text.

Defining Macros in the Makefile

A macro definition line is a makefile line with a macro name, an equals sign “=”, and a macro value. In the makefile, expressions of the form $(name) or ${name} are replaced with value. If the macro name is a single letter, the parentheses or braces are optional (i.e. $X, $(X) and ${X} all mean “the value of macro X”).

Here is the above example written with the introduction of four macros:

OBJS = main.obj io.obj MODEL = s CC = bcc CFLAGS = –m$(MODEL) 

project.exe : $(OBJS)  tlink c0$(MODEL) $(OBJS), project.exe,, c$(MODEL) /Lf:\bc\lib 

main.obj : main.c  $(CC) $(CFLAGS) –c main.c 

io.obj : io.c  $(CC) $(CFLAGS) –c io.c 

$(OBJS) : incl.h 

The value of the OBJS macro is the list of object files to be compiled. The macro definitions for MODEL, CC and CFLAGS were introduced so that it is easier to change the compiler memory model, name of the C compiler and its options.

Make automatically imports environment variables as macros, so you can reference an environment variable such as PATH with the makefile expression $(PATH).

Defining Macros on the Command Line

Macros can be defined on the Make command line. For example:

make CFLAGS=–ms 

would start up Make and define the macro CFLAGS with the value “–ms”. Macros defined on the command line take precedence over macros of the same name defined in the makefile.

If a command-line macro contains spaces, it must be enclosed in double quotes as in:

make "CFLAGS=-ms -z -p" 

Run-Time Macros

Make defines some special macros whose values are set dynamically. These macros return information about the current target being built. As examples, the .TARGET macro is name of the current target, the.SOURCE [2] macro is the name of the inferred source (from an inference rule) or the first of the explicit sources and the .SOURCES [3] macro is the list of all sources.

Using run-time macros the example can be written:

OBJS = main.obj io.obj CC = bcc MODEL = s CFLAGS = –m$(MODEL) 

project.exe : $(OBJS)  tlink c0$(MODEL) $(OBJS), $(.TARGET),, c$(MODEL) /Lf:\bc\lib 

main.obj : main.c  $(CC) $(CFLAGS) –c $(.SOURCE) 

io.obj : io.c  $(CC) $(CFLAGS) –c $(.SOURCE) 

 $(OBJS) : incl.h 

As you can see, the shell lines for updating main.obj and io.obj are identical when run-time macros are used. Run-time macros are important for generalizing the build process with inference rules, as shown on Page .

Macro Modifiers [Top]

Macros are used to reduce the amount of repeated text. They are also used in inference rules to generalize the build process. We often want to start with the value of a macro and modify it in some manner. For example, to get the list of source files from the OBJS macro we can do:

SRCS = $(OBJS,.obj=.c) 

This example uses the “from=to” macro modifier to replace the from text in the expansion of OBJS with the to text. The result is that $(SRCS) is “main.c io.c”. In general, to modify a macro expand it with:

$(name,modifier[,modifier ...]) 

Each modifier is applied in succession to the expanded value of name. Each modifier is separated from the next with a comma.

Filename Components

There is a set of macro modifiers for accessing parts of file names. For example, with the macro definition:

SRCS = d:\src\main.c io.asm 

Some of the modifiers are:

Modifier, and description	Example	Value
D, the directory	$(SRCS,D)	d:\src .
E, the extension (or suffix)	$(SRCS,E)	.c .asm
F, the file name	$(SRCS,F)	main.c io.asm

Tokenize

Another modifier is the “Wstr” modifier, which replaces whitespace between elements of the macro with str, a string. The str can be a mix of regular characters and special sequences, the most important sequence being “\n” which represents a newline character (like hitting the enter key). For example:

$(OBJS,W space +\n) is  main.obj +     io.obj

Other Modifiers

Other modifiers include: “@” (include file contents), “LC” (lower case), “UC” (upper case), “M” (member) and “N” (non-member). The “M” and “N” modifiers and the “S” (substitute) modifier use regular expressions for powerful and flexible pattern-matching. See Page for more information on all macro modifiers.

Inference Rules [Top]

Inference rules generalize the build process so you don't have to give an explicit rule for each target. As an example, compiling C source (.c files) into object files (.obj files) is a common occurrence. Rather than requiring a statement that each .obj file depends on a like-named .c file, Make uses an inference rule to infer that dependency. The source determined by an inference rule is called the inferred source.

Inference rules are rules distinguished by the use of the character “%” in the dependency line. The “%” (rule character) is a wild card, matching zero or more characters. As an example, here is an inference rule for building .obj files from .c files:

%.obj : %.c  $(CC) $(CFLAGS) –c $(.SOURCE) 

This rule states that a .obj file can be built from a corresponding .c file with the shell line “$(CC) $(CFLAGS) –c $(.SOURCE)”. The .c and .obj files share the same root of the file name.

When the source and target have the same file name except for their extensions, this rule can be specified in an alternative way:

.c.obj :  $(CC) $(CFLAGS) –c $(.SOURCE) 

The alternative form is compatible with Opus Make prior to this version and with other make utilities and is discussed in more detail on Page .

Make predefines the “%.obj : %.c” inference rule as listed above so the example we have been working on now becomes much simpler:

OBJS = main.obj io.obj CC = bcc MODEL = s CFLAGS = –m$(MODEL) 

project.exe : $(OBJS)  tlink c0$(MODEL) $(OBJS), $(.TARGET),, c$(MODEL) /Lf:\bc\lib 

$(OBJS) : incl.h 

Response Files [Top]

For MS-DOS, OS/2 & Win95 there is a rather severe restriction on the length of a shell line with the result that the shell line is often too short for many compilers and far too short for linkers and librarians.

To overcome this restriction many programs can receive command-line input from a response file. Opus Make has two kinds of support for response files: automatic response files, where Make decides when to build a response file or; inline response files, where you write response file-creating statements directly in the makefile.

Automatic Response Files

Make has predefined support for several linkers, librarians and compilers, and you can augment Make's support by writing your own definitions (see Page ). With Make's predefined support you can just add the following statement to your makefile:

.RESPONSE.LINK : tlink

This tells Make that the program tlink accepts LINK-style response files. When a shell line executes tlink, Make checks if the shell line is longer than allowed by the operating system and automatically produces a response file if necessary.

Inline Response Files

Response files can also be coded “inline” in your makefile. Here is the tlink shell line of the example, written to use an inline response file:

project.exe : $(OBJS)  tlink @<<> 

The tlink program is invoked as “tlink @response_file” where response_file is a name generated by Make. The “W+\n” macro modification replaces whitespace between elements of $(.SOURCES) with “+enter”. The response_file contains:

c0s main.obj+ io.obj project.exe  c0 /f:\bc\lib 

Makefile Directives [Top]

Makefile directives control the makefile lines Make reads at read time. Here is our example extended with conditional directives (%if, %elif, %else and %endif) to support both Borland and Microsoft compilers. Comments have been added for documentation:

# This makefile compiles the project listed in the PROJ macro # PROJ = project   # the name of the project OBJS = main.obj io.obj  # list of object files 

# Configuration: # MODEL = s   # memory model CC = bcc   # name of compiler 

# Compiler-dependent section # %if $(CC) == bcc  # if compiler is bcc   CFLAGS = –m$(MODEL)  # $(CFLAGS) is –ms   LDSTART = c0$(MODEL)  # the start-up object file   LDLIBS = c$(MODEL)  # the library   LDFLAGS = /Lf:\bc\lib  # f:\bc\lib is library directory %elif $(CC) == cl  # else if compiler is cl   CFLAGS = –A$(MODEL,UC) # $(CFLAGS) is –AS   LDSTART =   # no special start-up   LDLIBS =   # no special library   LDFLAGS = /Lf:\c6\lib; # f:\c6\lib is library directory %else    # else % abort Unsupported CC==$(CC) # compiler is not supported %endif    # endif 

# The project to be built # $(PROJ).exe : $(OBJS)  tlink $(LDSTART) $(OBJS), $(.TARGET),, $(LDLIBS) $(LDFLAGS) 

$(OBJS) : incl.h 

The layout of this makefile is fairly traditional — macros are defined first, the primary target follows the macros and the extra dependency information is last.

This example also uses the %abort directive to abort Make if the makefile does not support a particular compiler. Directives can also be used at run time, to control the shell lines Make executes. For more information about directives, see Page .

---

Footnotes

[1]You may be accustomed to “source” meaning a file containing source code. We will say “source file” when we mean this.

[2]This was called .IMPLICIT in Opus Make v5.2x and you can still use that name for .SOURCE.

[3]This was called .ALL in Opus Make v5.2x and you can still use that name for .SOURCES.