Re: [Mingw-users] Secondary expansion & target-specific variable problem in Makefile

[Tuomo L. <dj...@ik...>]

On 24.12.2014 15:15, 孔涛 wrote:
> Hello,everyone
> 
> How to set different prerequisites for the same target when it belong to a different target. For example,
> target t1 depends on file main.o and t1.o where main.o depend on t1.o (it's a module file in fortran, similar as a head file .h in C) besides its source, while
> target t2 depends on file main.o and t2.o where at this time main.o depends on t2.o together with it's souce file.  i.e
> --------------------------
> t1 : main.o t1.o
> main.o:   t1.o
> -------
> t2:main.o t2.o
> main.o:  t2.o
> -------------------------
> I wrote them together in one makefile, but unforturanatly, the dependece of main.o does not take effect. why?
> --
>      1    .SECONDEXPANSION:
>      2   
>      3    FC=gfortran
>      4    PRJ = t1 t2
>      5   
>      6    all: $(PRJ)
>      7   
>      8    %.o:%.f90 ; $(FC) -c $<
>      9   
>     10   
>     11    t1: tname = t1.o
>     12    t2: tname = t2.o
>     13   
>     14    $(PRJ) : main.o $$(tname) ; $(FC) $^ -o $@
>     15    main.o : $$(tname)
>     16   
>     17    clean:
>     18        rm -rf $(PRJ) *.o *.mod
> ----
> line 15 doesnot make any sense. why?

AFAIK make generally likes to spawn new child processes to handle each
of the dependencies (and each command line within rules), so naturally
variables won't stay set across targets.
To be sure you'd have to set (environment?) variables in the parent make,
if you want sticky variables, but I think you can find better ways to
organize the build.

For example, does main really need the t1/t2 dependency?
In this case you don't, so you could simply remove it. If you really
need to produce two different implementations using the same main with
different dependencies (which is fairly ugly), you can put the
compilation of the common file as a command within t1 and t2 rules or
some separate dummy targets.
Frankly, you should, in general, refactor your projects so that there are
no circular dependencies or these kinds of logical loops. In C/C++, you'd
generally use header files to separate the (common) interface for the
dependencies (t1/t2) from their implementation in order to allow main
to be compiled separately without these sort of problems.

Also, are you sure the syntax on lines 11 and 12 is correct?
And have you noticed that line 8 also defines the compilation of main.o?
Are you sure you're not hitting that rule instead of lines 11, 12 and 15?

The thing about makefiles is that if you're trying to be too clever,
you still tend to end up making your cool, generic ruleset
a) unelegant and uncool,
b) unportable,
c) longer than the simpler ruleset that is equally uncool and unelegant,
   but portable and robust even if it includes lines and rules that look
   copy-pasted,
d) not-really-generic because you still need to nail down the specifics
   and end up doing it in the weeds hidden behind complicated logic
   rather than visibly up front, and
e) making it unnecessarily difficult to modify, should you need to
   e.g. after having refactored your code.

Just some things to consider.


> here are the source file:
> ------------------------
> --main.f90--
> use eqn
> print *,nam
> end
> 
> --t1.f90--
> module eqn
>     character(10):: nam = 't1'
> end module
> 
> --t2.f90---
> module eqn
>     character(10):: nam = 't2'
> end module


-- 
Tuomo

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com