GNU Make question - how to write a rule for such a situation - Thread - go-pugleaf

Thread View: comp.unix.programmer

4 messages

[T] Back to Threads [V] Tree View [G] Group Articles

4 total messages Started by Gupit Thu, 31 Jan 2002 20:29

GNU Make question - how to write a rule for such a situation

#3757

Author: Gupit
Date: Thu, 31 Jan 2002 20:29

57 lines
2700 bytes

Hi,
I am trying to automate a process using GNU Make. 

I have a target say
CREATE_TRACES: $(trace_files)

$(trace_files) is a dynamically generated list of files and expands to
say
1.trace, 2.trace, 3.trace etc at runtime.

Now these trace files themselves are generated using a command say
genTrace. The trace files are generated as a side effect of this
command and are not  direct output. Also, all the trace files are
generated all at once when I run genTrace.
So "genTrace -options" creates 1.trace, 2.trace etc all at the same
time.

If I write

$(trace_files): command.rc
         genTrace -options

make -j will fire off genTrace for each of the .trace file. This is
not what I want.

Trying to use an implicit rule such as
%$(trace_files): %command.rc
        genTrace -options
which will tell make -j to consider the trace targets to depend on the
same command didnt work.
I was trying to do something of the sort:
%fileA %fileB: %fileC
         <command that generates fileA and fileB at the same time>

To get around this I wrote the rule as follow:

$(trace_files): trace_files_created

trace_files_created: command.rc
        genTrace -options && touch $@

This works, but is not clean. If for some reason, trace_files_created
exists, then there is absolutely no check for $(trace_files) and make
considers CREATE_TRACES uptodate. I want make to check if the .trace
files indeed exist before considering CREATE_TRACES uptodate.

I have two questions:
- Is there a way to write the implicit rule as above so I don't have a
intermediate file.

- How do I structure the rules above in a cleaner, efficient way? I
feel what I did is a hack at most.

I am using GNU Make version 3.79.1 on Solaris and Linux.

Much Thanks,
Bill

Re: GNU Make question - how to write a rule for such a situation

#3758

Author: Eli Zaretskii
Date: Fri, 01 Feb 2002 07:12

13 lines
1378 bytes

Gupit wrote:
> 
> If I write
> 
> $(trace_files): command.rc
>          genTrace -options
> 
> make -j will fire off genTrace for each of the .trace file. This is
> not what I want.

Is the parallelism the only problem with this solution, or are there other
problems?  If parallel execution is the only issue, why not force Make to
not fire parallel jobs?

Re: GNU Make question - how to write a rule for such a situation

#3759

Author: Gupit
Date: Fri, 01 Feb 2002 18:44

21 lines
1762 bytes

Eli Zaretskii <eliz@is.elta.co.il> wrote in message news:<3C5A3FE4.6AEF7129@is.elta.co.il>...
> Gupit wrote:
> > 
> > If I write
> > 
> > $(trace_files): command.rc
> >          genTrace -options
> > 
> > make -j will fire off genTrace for each of the .trace file. This is
> > not what I want.
> 
> Is the parallelism the only problem with this solution, or are there other
> problems?  If parallel execution is the only issue, why not force Make to
> not fire parallel jobs?

I do want to use parallelism in the other parts of the Makefile. I
could get around by making it a recursive make target and specifying
j=0 or something. But does that mean there isnt a elegant solution to
this type of target-dependency problem in GNU make?
Thanks,
Gupit

Re: GNU Make question - how to write a rule for such a situation

#3760

Author: Eli Zaretskii
Date: Fri, 01 Feb 2002 19:27

19 lines
1831 bytes

Gupit wrote:
> 
> > Is the parallelism the only problem with this solution, or are there other
> > problems?  If parallel execution is the only issue, why not force Make to
> > not fire parallel jobs?
> 
> I do want to use parallelism in the other parts of the Makefile. I
> could get around by making it a recursive make target and specifying
> j=0 or something.

You could either make this target invoke a recursive Make that is not
parallel, or make this target be a prerequisite of a special target
.NOTPARALLEL.

> But does that mean there isnt a elegant solution to
> this type of target-dependency problem in GNU make?

I don't think these solutions aren't elegant, and I don't know about any
more elegant ones.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads