bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of $* in computed dependencies


From: Ted Stern
Subject: Re: Use of $* in computed dependencies
Date: Thu, 23 Jan 2003 13:44:23 -0800
User-agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (sparc-sun-solaris2.8)

On Thu, 23 Jan 2003, Herb W. Swan wrote:
> 
> Sorry, I made a slight misstatement in my earlier post, corrected
> below.  Thank you for reading this post.
> ---------------------------------------------------------------------
> 
> This is not a bug, but a neat feature that would open the door
> to improved functionality, as far as I can see.
> 
> The following makefile doesn't do what I had hoped it would:
> 
> all:    b.logvsh
> 
> b_depend := a.raw.mod
> 
> %.logvsh:       $($*_depend) %.mod
>       @echo   make $@
> 
> %.raw.mod:
>       @echo   make $@
> 
> %.mod:
>       @echo   make $@
>

HI Herb,

I think I see what you are after here, because it looks similar to a problem
that occurs with fortran 90 compiler-generated module files.

Background, in case the .mod file doesn't come from fortran 90:

        http://www.theochem.uwa.edu.au/fortran/recompile/

In fortran 90 and above, compiling a fortran 90 file may generate a ".mod"
file containing the interfaces and information needed by some other fortran
file.  Unfortunately the generated file may have a completely different
basename than the original source file.  In fact, there could be several
generated files.

It is possible to deal with this sort of situation without recursive make
calls:

      %.depend:   %.source
             run the makedepend script

      %.object:   %.source
             usual compile command

      %.byproduct:  # NO PATTERN DEPENDENCY HERE -- added explicitly below
             test for existence -- if not there, delete first dependency
             and call make recursively to regenerate first dependency


      include $(automatically_generated_depend_files)

The makedepend script generates lines like the following:

      a.byproduct:   b.object
      b.object:      assorted include files and possibly other byproduct files

In the fortran 90 case, there is an additional complication that a source
change might not create any meaningful difference in the byproduct files, but
the timestamp on the byproduct files changes anyway.  So you need some method
to compare byproduct files before and after the compile step to see if they've
changed or not.  I use a script called "byproduct_build.perl", attached below,
to wrap around the compile command for this purpose.

Note that if the byproduct files are out of date with respect to the object
file, you'll still go into the %.byproduct rule, but if the byproduct file
exists, the rule exits and files that depend on it won't get recompiled in a
compilation cascade.

Ted
-- 
 Ted Stern                           Engineering Applications
 Cray Inc.                               office: 206-701-2182
 411 First Avenue South, Suite 600         cell: 206-383-1049
 Seattle, WA 98104-2860                     FAX: 206-701-2500
 Debuggers' motto:  Frango ut patefaciam -- I break in order to reveal

Attachment: byproduct_build.perl
Description: byproduct_build.perl


reply via email to

[Prev in Thread] Current Thread [Next in Thread]