[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