Re: Request for critique on a small makefile

[Philip Guenther]

On 12/12/06, Edward Z. Yang <address@hidden> wrote:
> Philip Guenther wrote:
...
> > all : ${programs}
> >
> > clean:
> >        ${RM} ${programs} *.o
>
> Regarding number two, these two don't edit $@, does that mean we need a
> .PHONY rule?

Good eye.  It's preferable, but not necessary.  Now that I think about
it, rule #2 is actually stated slightly stricter than it really needs
to be.  The key bit is that if the point of a rule is to create a
file, then the target of the rule must be that file.  Otherwise the
timestamp comparison used by make won't work because it won't find the
file that was updated.  For the other direction, rules that don't
update a specific file, well, the info pages describe why you should
use the .PHONY declaration:

   4.6 Phony Targets
   =================

   A phony target is one that is not really the name of a file.  It is
   just a name for some commands to be executed when you make an explicit
   request.  There are two reasons to use a phony target: to avoid a
   conflict with a file of the same name, and to improve performance.

...it then goes on to explain the details of both reasons.  The
performance effect is quite small in general, so as long as you aren't
worried about accidentally creating a file named 'all' or 'clean' in
the directory, you don't really need the .PHONY.  A *lot* of makefile
leave it out.  But yes, it's good practice.


> > fibonacci: fibonacci.o
> >        ${LINK.cc} -o $@ $< ${boostlib}
>
> A lot of variables used here.
> ${LINK.cc} is a macro for a C++ linker with all the options we specified
> above
> $@ is the target of the rule
> $< are the prerequisites (one or all of them?)
> ${boostlib} is the var we stated

Correct.  Regarding $<, we turn to the info pages again:

   10.5.3 Automatic Variables
   --------------------------
...
   `$<'
       The name of the first prerequisite.  If the target got its
        commands from an implicit rule, this will be the first
        prerequisite added by the implicit rule (*note Implicit Rules::).


...
> > - as it traditionaly under UNIX, the executables don't have a .exe
> > suffix.  If you *really*
> >   want the suffix, you would do the following:
> >   1) change the value of the 'programs' variable
> >   2) add the .exe suffix to just the target in the rule for linking
> > fibonacci
> >   3) add a rule for linking printNumbers.exe similar to the one for
> > fibonacci.exe
>
> I'm running GNU make of a cygwin compatibility layer. As is, the
> executables are magically getting .exe suffixes, breaking `make clean`.
> How do I fix this?

Ah.  Hmm.  My *guess* is that g++ will only add the .exe suffix if
there isn't already such a suffix present.  If so, then following the
three points I listed should work.


> Regarding the auto-exe output, when I run `make -n`, I get the same
> result, so it's not g++'s fault. Cygwin?

Hmm?  Running 'make -n' shows what command make would execute.  If
executing the command (imagine this as one line)
   g++ -ansi -pedantic -I/usr/include/boost-1_33_1 printNumbers.cpp
          -o printNumbers

results in the file printNumbers.exe being created, then it *must* be
g++ that's adding the .exe.


> Also, is gmake the name of your make executable or simply an alias to
> make to make sure any other programs named make don't conflict?

There's a standard configure option for adding a prefix to the
executable name when installed.  I use that because I use OpenBSD and
need access to the 'make' included with the system for when I'm
compiling the system itself or building stuff using its 'ports'
system.


Philip Guenther