Re: Problem with Prerequisite Patterns -- possible bug??

[Paul D. Smith]

%% "Andrew L. Bereson" <address@hidden> writes:

  alb> I am updating a makefile for a system that has components running
  alb> on several different hardware architectures.

  alb> The current Makefile uses the following rules with associated defs:

  alb> OBJSmach1= ../../obj/mach1/file.o ../../obj/mach1/file2.o
  alb> etc...

  alb> $(OBJSmach1):    $(@F:.o=.c)
  alb>      gcc -c -o $@ $<

No it doesn't.  I'm sure you mean:

 $(OBJSmach1):  $$(@F:.o=.c)
                ^^
(note the double, not single, '$').

  alb> This works great under all of our various UNIX's,

That just means all your other versions of UNIX are derived from SysV.
The SysV version of make (and _only_ that version) provides this strange
feature.  This feature is not standard (it's not defined in POSIX) and
no other version of make (BSD, GNU, etc.) implements it... or hasn't
before now.  See below.

In short, this is not a portable feature.

  alb> I have looked at using the static rule stuff using '%' but I have
  alb> two problems with that...

  alb>  1) This is incompatable with the make running on all of the
  alb>     non-Linux machines

Correct.  Of course, your current implementation is incompatible with
all the makes running on non-SysV machines--and there's no source-
available implementation of SysV make so there's nothing you can do
about it.

My suggestion is this:

  Don't bother trying to write portable makefiles; use a portable _make_
  instead.

That is, if you can build GNU make on all the platforms you currently
have or expect to have (and GNU make runs on everything from UNIX to VMS
to Amiga to Windows), then just write your makefiles using as many of
GNU make's capabilities as you need and change your porting guidelines
from "fix all the weird incompatibilities with whatever version of make
is on the new target" to "build GNU make for the new target".

The latter is a much simpler proposition.

  alb>  2) Don't see a way to make a generic rule that totally strips
  alb>     the directory part off of the target to generate the
  alb>     prerequisite name without a-priori knowledge of the directory
  alb>     name (which, although it appears pretty straightforward in
  alb>     the example, it is less so in the real system)

This is a problem.  There are a number of ways to solve this.

 1) In GNU make 3.79.1 and before, you can use the auto-re-exec feature
    of GNU make: write a rule that generates a makefile fragment that
    contains the proper dependency lines: since you have the shell it's
    not hard to manage this.  Then include that fragment with a make
    "include" line.  GNU make always tries to rebuild any makefile that
    it reads, and if it can do so it automatically re-execs itself and
    starts over.

 2) In GNU make 3.80 you can use the $(eval ...) function to create
    dynamic content directly, without re-exec.

Both of the above will require you to switch to GNU make on all your
platforms.

 3) GNU make 3.80 introduces a compatibility mode for SysV make and it
    understands $$@, $$(@D), and $$(@F).  Unfortunately it doesn't
    understand the replacement syntax, like $$(@F:.o=.c).  That will
    probably be implemented in the next version--so you could wait for
    that.

    Or, implement it yourself--that's one of the great things about free
    software :).

  alb> Until now, we have succeeded with a single common Makefile for
  alb> all of our machines.

You've been lucky so far in your choice of target systems.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist