help-make
[Top][All Lists]
Advanced

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

Re: Target driven rule building


From: Reinier Post
Subject: Re: Target driven rule building
Date: Mon, 12 Jan 2015 17:00:00 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun Jan 11 23:34:48 2015, address@hidden (Oliver Burghard) wrote:
> Hello, 
> 
> 
> I have the following problem, that I am sure other people had as
> well and wonder if it is possible with make or if somebody knows a
> different program well suited instead.
> 
> I have a collection of files >100 that I need to process via
> multiple steps >10 into several results (some depend on
> multiple/all input files).
> 
> Now the processing rules also depend on parameters, that depend on
> the source and target file names.

You can use target-specific variables:

  https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html

> I want to describe the build process as simple as possible.
> Formulating all rules is no choice. Implicit rules are no 'good'
> choice as their pattern matching is too weak. Targets differ in
> more than one place.

My Makefile From Hell has the same problem.  Targets can have up to
4 or 5 different '%' parts and pattern rules support only 1.

What I've done is use variables for the variable parts, with
define/endef sections to write thee rules and foreach+call+eval loops
to set the variables to each of their possible values.
This is a maintainability nightmare, the syntax
and semantics are way too hard for me to cope with.

> What would be much better are rules automatically build for targets
> matching a regular expression. And optimally the rule would depend
> on the target name and on 'properties' assigned to the source files
> - many can possibly be inferred from its name. Also I could use
> hash maps to match part of file names onto parameter sets.
> 
> Is it formulated well enough to be understood? Any help or link how
> this can be implemented in a nice (manageable) way is appreciated.

The problem has been discussed on this list several times,
but I don't recall seeing a good solution.

So my suggestion is that you scan the archives to see how your idea
 relates to what others have already proposed.

> Thanks, Oliver Burghard

-- 
Reinier Post
TU Eindhoven



reply via email to

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