├── .gitignore
├── Doxyfile
├── README.md
├── Remakefile
├── remake.cpp
└── testsuite
├── all.sh
├── t001.sh
├── t002.sh
├── t003.sh
├── t004.sh
├── t005.sh
├── t006.sh
├── t007.sh
├── t008.sh
├── t009.sh
├── t010.sh
├── t011.sh
├── t012.sh
├── t013.sh
├── t014.sh
└── t015.sh
/.gitignore:
--------------------------------------------------------------------------------
1 | /doxydoc
2 | /remake
3 | /remake.exe
4 | /.remake
5 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | Remake, a build system that bridges the gap between make and redo
2 | =================================================================
3 |
4 | As with make, remake uses a centralized rule file, which is
5 | named Remakefile. It contains rules with a make-like
6 | syntax:
7 |
8 | target1 target2 ... : prerequisite1 prerequisite2 ...
9 | shell script
10 | that builds
11 | the targets
12 |
13 | A target is known to be up-to-date if all its prerequisites are. If it
14 | has no known prerequisites yet the file already exits, it is assumed to
15 | be up-to-date. Obsolete targets are rebuilt thanks to the shell script
16 | provided by the rule.
17 |
18 | As with redo, remake supports dynamic dependencies in
19 | addition to these static dependencies. Whenever a script executes
20 | `remake prerequisite4 prerequisite5 ...`, these prerequisites are
21 | rebuilt if they are obsolete. (So remake acts like
22 | redo-ifchange.) Moreover, all the dependencies are stored in file
23 | .remake so that they are remembered in subsequent runs. Note that
24 | dynamic dependencies from previous runs are only used to decide whether a
25 | target is obsolete; they are not automatically rebuilt when they are
26 | obsolete yet a target depends on them. They will only be rebuilt once the
27 | dynamic call to remake is executed.
28 |
29 | In other words, the following two rules have almost the same behavior.
30 |
31 | target1 target2 ... : prerequisite1 prerequisite2 ...
32 | shell script
33 |
34 | target1 target2 ... :
35 | remake prerequisite1 prerequisite2 ...
36 | shell script
37 |
38 | (There is a difference if the targets already exist, have never been
39 | built before, and the prerequisites are either younger or obsolete, since
40 | the targets will not be rebuilt in the second case.)
41 |
42 | The above usage of dynamic dependencies is hardly useful. Their strength
43 | lies in the fact that they can be computed on the fly:
44 |
45 | %.o : %.c
46 | gcc -MMD -MF $@.d -o $@ -c $<
47 | remake -r < $@.d
48 | rm $@.d
49 |
50 | %.cmo : %.ml
51 | ocamldep $< | remake -r $@
52 | ocamlc -c $<
53 |
54 | after.xml: before.xml rules.xsl
55 | xsltproc --load-trace -o after.xml rules.xsl before.xml 2> deps
56 | remake `sed -n -e "\\,//,! s,^.*URL=\"\\([^\"]*\\).*\$,\\1,p" deps`
57 | rm deps
58 |
59 | Note that the first rule fails if any of the header files included by
60 | a C source file has to be automatically generated. In that case, one
61 | should perform a first call to remake them before calling the
62 | compiler. (Dependencies from several calls to remake are
63 | cumulative, so they will all be remembered the next time.)
64 |
65 | Usage
66 | -----
67 |
68 | Usage: remake options targets
69 |
70 | Options:
71 |
72 | - `-B`, `--always-make`: Unconditionally make all targets.
73 | - `-d`: Echo script commands.
74 | - `-f FILE`: Read `FILE` as Remakefile.
75 | - `-j[N]`, `--jobs=[N]`: Allow `N` jobs at once;
76 | infinite jobs with no argument.
77 | - `-k`, `--keep-going`: Keep going when some targets cannot be made.
78 | - `-r`: Look up targets from the dependencies on standard input.
79 | - `-s`, `--silent`, `--quiet`: Do not echo targets.
80 |
81 | Syntax
82 | ------
83 |
84 | Lines starting with a space character or a tabulation are assumed to be rule
85 | scripts. They are only allowed after a rule header.
86 |
87 | Lines starting with `#` are considered to be comments and are ignored.
88 | They do interrupt rule scripts though.
89 |
90 | Any other line is either a variable definition or a rule header. If such a
91 | line ends with a backslash, the following line break is ignored and the line
92 | extends to the next one.
93 |
94 | Variable definitions are a single name followed by equal followed by a list
95 | of names, possibly empty.
96 |
97 | Rule headers are a nonempty list of names, followed by a colon, followed by
98 | another list of names, possibly empty. Basically, the syntax of a rule is as
99 | follows:
100 |
101 | targets : prerequisites
102 | shell script
103 |
104 | List of names are space-separated sequences of names. If a name contains
105 | a space character, it should be put into double quotes. Names cannot be
106 | any of the following special characters `:$(),="`. Again, quotation
107 | should be used. Quotation marks can be escaped by a backslash inside
108 | quoted names.
109 |
110 | ### Variables
111 |
112 | Variables can be used to factor lists of targets or prerequisites. They are
113 | expanded as they are encountered during Remakefile parsing.
114 |
115 | VAR2 = a
116 | VAR1 = c d
117 | VAR2 += $(VAR1) b
118 | $(VAR2) e :
119 |
120 | Variable assignments can appear instead of prerequisites inside non-generic
121 | rules with no script. They are then expanded inside the corresponding
122 | generic rule.
123 |
124 | foo.o: CFLAGS += -DBAR
125 |
126 | %.o : %.c
127 | gcc $(CFLAGS) -MMD -MF $@.d -o $@ -c $<
128 | remake -r < $@.d
129 | rm $@.d
130 |
131 | Note: contrarily to make, variable names have to be enclosed in
132 | parentheses. For instance, `$y` is not a shorthand for `$(y)` and
133 | is left unexpanded.
134 |
135 | ### Automatic variables
136 |
137 | The following special symbols can appear inside scripts:
138 |
139 | - `$<` expands to the first static prerequisite of the rule.
140 | - `$^` expands to all the static prerequisites of the rule, including
141 | duplicates if any.
142 | - `$@` expands to the first target of the rule.
143 | - `$*` expands to the string that matched `%` in a generic rule.
144 | - `$$` expands to a single dollar symbol.
145 |
146 | Note: contrarily to make, there are no corresponding variables.
147 | For instance, `$^` is not a shorthand for `$(^)`. Another difference is
148 | that `$@` is always the first target, not the one that triggered the
149 | rule.
150 |
151 | ### Built-in functions
152 |
153 | remake also supports a few built-in functions inspired from make.
154 |
155 | - $(addprefix prefix, list) returns the list obtained
156 | by prepending its first argument to each element of its second argument.
157 | - $(addsuffix suffix, list) returns the list obtained
158 | by appending its first argument to each element of its second argument.
159 |
160 | ### Order-only prerequisites
161 |
162 | If the static prerequisites of a rule contain a pipe symbol, prerequisites
163 | on its right do not cause the targets to become obsolete if they are newer
164 | (unless they are also dynamically registered as dependencies). They are
165 | meant to be used when the targets do not directly depend on them, but the
166 | computation of their dynamic dependencies does.
167 |
168 | %.o : %.c | parser.h
169 | gcc -MMD -MF $@.d -o $@ -c $<
170 | remake -r < $@.d
171 | rm $@.d
172 |
173 | parser.c parser.h: parser.y
174 | yacc -d -o parser.c parser.y
175 |
176 | ### Static pattern rules
177 |
178 | A rule with the following structure is expanded into several rules, one
179 | per target.
180 |
181 | targets: pattern1 pattern2 ...: prerequisites
182 |
183 | Every target is matched against one of the patterns containing the `%`
184 | character. A rule is then created using the patterns as targets, after
185 | having substituted `%` in the patterns and prerequisites. The automatic
186 | variable `$*` can be used in the script of the rule.
187 |
188 | ### Special targets
189 |
190 | Target `.PHONY` marks its prerequisites as being always obsolete.
191 |
192 | ### Special variables
193 |
194 | Variable `.OPTIONS` is handled specially. Its content enables some
195 | features of remake that are not enabled by default.
196 |
197 | - `variable-propagation`: When a variable is set in the prerequisite
198 | part of a rule, it is propagated to the rules of all the targets this rule
199 | depends on. Note that, as in make, this feature introduces
200 | non-determinism: the content of some variables will depend on the build order.
201 |
202 | Semantics
203 | ---------
204 |
205 | ### When are targets obsolete?
206 |
207 | A target is obsolete:
208 |
209 | - if there is no file corresponding to the target, or to one of its siblings
210 | in a multi-target rule,
211 | - if any of its dynamic prerequisites from a previous run or any of its static
212 | prerequisites is obsolete,
213 | - if the latest file corresponding to its siblings or itself is older than any
214 | of its dynamic prerequisites or static prerequisites.
215 |
216 | In all the other cases, it is assumed to be up-to-date (and so are all its
217 | siblings). Note that the last rule above says "latest" and not "earliest". While
218 | it might cause some obsolete targets to go unnoticed in corner cases, it allows
219 | for the following kind of rules:
220 |
221 | config.h stamp-config_h: config.h.in config.status
222 | ./config.status config.h
223 | touch stamp-config_h
224 |
225 | A `config.status` file generally does not update header files (here
226 | `config.h`) if they would not change. As a consequence, if not for the
227 | `stamp-config_h` file above, a header would always be considered obsolete
228 | once one of its prerequisites is modified. Note that touching `config.h`
229 | rather than `stamp-config_h` would defeat the point of not updating it in
230 | the first place, since the program files would need to be rebuilt.
231 |
232 | Once all the static prerequisites of a target have been rebuilt, remake
233 | checks whether the target still needs to be built. If it was obsolete only
234 | because its prerequisites needed to be rebuilt and none of them changed, the
235 | target is assumed to be up-to-date.
236 |
237 | ### How are targets (re)built?
238 |
239 | There are two kinds of rules. If any of the targets or prerequisites contains
240 | a `%` character, the rule is said to be generic. All the
241 | targets of the rule shall then contain a single `%` character. All the
242 | other rules are said to be specific.
243 |
244 | A rule is said to match a given target:
245 |
246 | - if it is specific and the target appears inside its target list,
247 | - if it is generic and there is a way to replace the `%` character
248 | from one of its targets so that it matches the given target.
249 |
250 | When remake tries to build a given target, it looks for a specific rule
251 | that matches it. If there is one and its script is nonempty, it uses it to
252 | rebuild the target.
253 |
254 | Otherwise, it looks for a generic rule that matches the target. If there are
255 | several matching rules, it chooses the one with the shortest pattern (and if
256 | there are several ones, the earliest one). It then looks for specific rules
257 | that match each target of the generic rule. All the prerequisites of these
258 | specific rules are added to those of the generic rule. The script of the
259 | generic rule is used to build the target.
260 |
261 | Example:
262 |
263 | t%1 t2%: p1 p%2
264 | commands building t%1 and t2%
265 |
266 | t2z: p4
267 | commands building t2z
268 |
269 | ty1: p3
270 |
271 | # t2x is built by the first rule (which also builds tx1) and its prerequisites are p1, px2
272 | # t2y is built by the first rule (which also builds ty1) and its prerequisites are p1, py2, p3
273 | # t2z is built by the second rule and its prerequisite is p4
274 |
275 | The set of rules from Remakefile is ill-formed:
276 |
277 | - if any specific rule matching a target of the generic rule has a nonempty script,
278 | - if any target of the generic rule is matched by a generic rule with a shorter pattern.
279 |
280 | Compilation
281 | -----------
282 |
283 | - On Linux, MacOSX, and BSD: `g++ -o remake remake.cpp`
284 | - On Windows: `g++ -o remake.exe remake.cpp -lws2_32`
285 |
286 | Installing remake is needed only if Remakefile does not
287 | specify the path to the executable for its recursive calls. Thanks to its
288 | single source file, remake can be shipped inside other packages and
289 | built at configuration time.
290 |
291 | Differences with other build systems
292 | ------------------------------------
293 |
294 | Differences with make:
295 |
296 | - Dynamic dependencies are supported.
297 | - For rules with multiple targets, the shell script is executed only once
298 | and is assumed to build all the targets. There is no need for
299 | convoluted rules that are robust enough for parallel builds. For generic
300 | rules, this is similar to the behavior of pattern rules from gmake.
301 | - As with redo, only one shell is run when executing a script,
302 | rather than one per script line. Note that the shells are run with
303 | option `-e`, thus causing them to exit as soon as an error is
304 | encountered.
305 | - The prerequisites of generic rules (known as implicit rules in make
306 | lingo) are not used to decide between several of them, which means that
307 | remake does not select one for which it could satisfy the dependencies.
308 | - Variables and built-in functions are expanded as they are encountered
309 | during Remakefile parsing.
310 | - Target-specific variables are not propagated, unless specifically enabled,
311 | since this causes non-deterministic builds.
312 |
313 | Differences with redo:
314 |
315 | - As with make, it is possible to write the following kind of rules
316 | in remake.
317 |
318 | Remakefile: Remakefile.in ./config.status
319 | ./config.status Remakefile
320 |
321 | - If a target is already built the first time remake runs, it still
322 | uses the static prerequisites of rules mentioning it to check whether it
323 | needs to be rebuilt. It does not assume it to be up-to-date. As with
324 | redo though, if its obsolete status would be due to a dynamic
325 | prerequisite, it will go unnoticed; it should be removed beforehand.
326 | - Multiple targets are supported.
327 | - remake has almost no features: no checksum-based dependencies, no
328 | compatibility with job servers, etc.
329 |
330 | Limitations
331 | -----------
332 |
333 | - If a rule script calls remake, the current working directory should
334 | be the directory containing Remakefile (or the working directory
335 | from the original remake if it was called with option `-f`).
336 | - As with make, variables passed on the command line should keep
337 | the same values, to ensure deterministic builds.
338 | - Some cases of ill-formed rules are not caught by remake and can
339 | thus lead to unpredictable behaviors.
340 |
341 | Links
342 | -----
343 |
344 | See for the philosophy of redo and
345 | for an implementation and some comprehensive documentation.
346 |
347 | Licensing
348 | ---------
349 |
350 | Copyright (C) 2012-2024 Guillaume Melquiond
351 |
352 | This program is free software: you can redistribute it and/or modify
353 | it under the terms of the GNU General Public License as published by
354 | the Free Software Foundation, either version 3 of the License, or
355 | (at your option) any later version.
356 |
357 | This program is distributed in the hope that it will be useful,
358 | but WITHOUT ANY WARRANTY; without even the implied warranty of
359 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
360 | GNU General Public License for more details.
361 |
362 |
--------------------------------------------------------------------------------
/Remakefile:
--------------------------------------------------------------------------------
1 | remake: remake.cpp
2 | g++ -Wall -O0 -g -W remake.cpp -o remake
3 |
4 | check: remake
5 | cd testsuite
6 | ./all.sh
7 |
8 | doxydoc: remake.cpp
9 | doxygen
10 |
11 | .PHONY: check
12 |
--------------------------------------------------------------------------------
/remake.cpp:
--------------------------------------------------------------------------------
1 | /* -*- mode: C++; indent-tabs-mode: t; c-basic-offset: 8; -*- */
2 | /**
3 | @mainpage Remake, a build system that bridges the gap between make and redo.
4 |
5 | As with make, remake uses a centralized rule file, which is
6 | named Remakefile. It contains rules with a make-like
7 | syntax:
8 |
9 | @verbatim
10 | target1 target2 ... : prerequisite1 prerequisite2 ...
11 | shell script
12 | that builds
13 | the targets
14 | @endverbatim
15 |
16 | A target is known to be up-to-date if all its prerequisites are. If it
17 | has no known prerequisites yet the file already exits, it is assumed to
18 | be up-to-date. Obsolete targets are rebuilt thanks to the shell script
19 | provided by the rule.
20 |
21 | As with redo, remake supports dynamic dependencies in
22 | addition to these static dependencies. Whenever a script executes
23 | `remake prerequisite4 prerequisite5 ...`, these prerequisites are
24 | rebuilt if they are obsolete. (So remake acts like
25 | redo-ifchange.) Moreover, all the dependencies are stored in file
26 | .remake so that they are remembered in subsequent runs. Note that
27 | dynamic dependencies from previous runs are only used to decide whether a
28 | target is obsolete; they are not automatically rebuilt when they are
29 | obsolete yet a target depends on them. They will only be rebuilt once the
30 | dynamic call to remake is executed.
31 |
32 | In other words, the following two rules have almost the same behavior.
33 |
34 | @verbatim
35 | target1 target2 ... : prerequisite1 prerequisite2 ...
36 | shell script
37 |
38 | target1 target2 ... :
39 | remake prerequisite1 prerequisite2 ...
40 | shell script
41 | @endverbatim
42 |
43 | (There is a difference if the targets already exist, have never been
44 | built before, and the prerequisites are either younger or obsolete, since
45 | the targets will not be rebuilt in the second case.)
46 |
47 | The above usage of dynamic dependencies is hardly useful. Their strength
48 | lies in the fact that they can be computed on the fly:
49 |
50 | @verbatim
51 | %.o : %.c
52 | gcc -MMD -MF $@.d -o $@ -c $<
53 | remake -r < $@.d
54 | rm $@.d
55 |
56 | %.cmo : %.ml
57 | ocamldep $< | remake -r $@
58 | ocamlc -c $<
59 |
60 | after.xml: before.xml rules.xsl
61 | xsltproc --load-trace -o after.xml rules.xsl before.xml 2> deps
62 | remake `sed -n -e "\\,//,! s,^.*URL=\"\\([^\"]*\\).*\$,\\1,p" deps`
63 | rm deps
64 | @endverbatim
65 |
66 | Note that the first rule fails if any of the header files included by
67 | a C source file has to be automatically generated. In that case, one
68 | should perform a first call to remake them before calling the
69 | compiler. (Dependencies from several calls to remake are
70 | cumulative, so they will all be remembered the next time.)
71 |
72 | \section sec-usage Usage
73 |
74 | Usage: remake options targets
75 |
76 | Options:
77 |
78 | - `-B`, `--always-make`: Unconditionally make all targets.
79 | - `-d`: Echo script commands.
80 | - `-f FILE`: Read `FILE` as Remakefile.
81 | - `-j[N]`, `--jobs=[N]`: Allow `N` jobs at once;
82 | infinite jobs with no argument.
83 | - `-k`, `--keep-going`: Keep going when some targets cannot be made.
84 | - `-r`: Look up targets from the dependencies on standard input.
85 | - `-s`, `--silent`, `--quiet`: Do not echo targets.
86 |
87 | \section sec-syntax Syntax
88 |
89 | Lines starting with a space character or a tabulation are assumed to be rule
90 | scripts. They are only allowed after a rule header.
91 |
92 | Lines starting with `#` are considered to be comments and are ignored.
93 | They do interrupt rule scripts though.
94 |
95 | Any other line is either a variable definition or a rule header. If such a
96 | line ends with a backslash, the following line break is ignored and the line
97 | extends to the next one.
98 |
99 | Variable definitions are a single name followed by equal followed by a list
100 | of names, possibly empty.
101 |
102 | Rule headers are a nonempty list of names, followed by a colon, followed by
103 | another list of names, possibly empty. Basically, the syntax of a rule is as
104 | follows:
105 |
106 | @verbatim
107 | targets : prerequisites
108 | shell script
109 | @endverbatim
110 |
111 | List of names are space-separated sequences of names. If a name contains
112 | a space character, it should be put into double quotes. Names cannot be
113 | any of the following special characters `:$(),="`. Again, quotation
114 | should be used. Quotation marks can be escaped by a backslash inside
115 | quoted names.
116 |
117 | \subsection sec-variables Variables
118 |
119 | Variables can be used to factor lists of targets or prerequisites. They are
120 | expanded as they are encountered during Remakefile parsing.
121 |
122 | @verbatim
123 | VAR2 = a
124 | VAR1 = c d
125 | VAR2 += $(VAR1) b
126 | $(VAR2) e :
127 | @endverbatim
128 |
129 | Variable assignments can appear instead of prerequisites inside non-generic
130 | rules with no script. They are then expanded inside the corresponding
131 | generic rule.
132 |
133 | @verbatim
134 | foo.o: CFLAGS += -DBAR
135 |
136 | %.o : %.c
137 | gcc $(CFLAGS) -MMD -MF $@.d -o $@ -c $<
138 | remake -r < $@.d
139 | rm $@.d
140 | @endverbatim
141 |
142 | Note: contrarily to make, variable names have to be enclosed in
143 | parentheses. For instance, `$y` is not a shorthand for \$(y) and
144 | is left unexpanded.
145 |
146 | \subsection sec-autovars Automatic variables
147 |
148 | The following special symbols can appear inside scripts:
149 |
150 | - `$<` expands to the first static prerequisite of the rule.
151 | - `$^` expands to all the static prerequisites of the rule, including
152 | duplicates if any.
153 | - `$@` expands to the first target of the rule.
154 | - `$*` expands to the string that matched `%` in a generic rule.
155 | - `$$` expands to a single dollar symbol.
156 |
157 | Note: contrarily to make, there are no corresponding variables.
158 | For instance, `$^` is not a shorthand for `$(^)`. Another difference is
159 | that `$@` is always the first target, not the one that triggered the
160 | rule.
161 |
162 | \subsection sec-functions Built-in functions
163 |
164 | remake also supports a few built-in functions inspired from make.
165 |
166 | - $(addprefix prefix, list) returns the list obtained
167 | by prepending its first argument to each element of its second argument.
168 | - $(addsuffix suffix, list) returns the list obtained
169 | by appending its first argument to each element of its second argument.
170 |
171 | \subsection sec-order Order-only prerequisites
172 |
173 | If the static prerequisites of a rule contain a pipe symbol, prerequisites
174 | on its right do not cause the targets to become obsolete if they are newer
175 | (unless they are also dynamically registered as dependencies). They are
176 | meant to be used when the targets do not directly depend on them, but the
177 | computation of their dynamic dependencies does.
178 |
179 | @verbatim
180 | %.o : %.c | parser.h
181 | gcc -MMD -MF $@.d -o $@ -c $<
182 | remake -r < $@.d
183 | rm $@.d
184 |
185 | parser.c parser.h: parser.y
186 | yacc -d -o parser.c parser.y
187 | @endverbatim
188 |
189 | \subsection sec-static-pattern Static pattern rules
190 |
191 | A rule with the following structure is expanded into several rules, one
192 | per target.
193 |
194 | @verbatim
195 | targets: pattern1 pattern2 ...: prerequisites
196 | @endverbatim
197 |
198 | Every target is matched against one of the patterns containing the `%`
199 | character. A rule is then created using the patterns as targets, after
200 | having substituted `%` in the patterns and prerequisites. The automatic
201 | variable `$*` can be used in the script of the rule.
202 |
203 | \subsection sec-special-tgt Special targets
204 |
205 | Target `.PHONY` marks its prerequisites as being always obsolete.
206 |
207 | \subsection sec-special-var Special variables
208 |
209 | Variable `.OPTIONS` is handled specially. Its content enables some
210 | features of remake that are not enabled by default.
211 |
212 | - `variable-propagation`: When a variable is set in the prerequisite
213 | part of a rule, it is propagated to the rules of all the targets this rule
214 | depends on. Note that, as in make, this feature introduces
215 | non-determinism: the content of some variables will depend on the build order.
216 |
217 | \section sec-semantics Semantics
218 |
219 | \subsection src-obsolete When are targets obsolete?
220 |
221 | A target is obsolete:
222 |
223 | - if there is no file corresponding to the target, or to one of its siblings
224 | in a multi-target rule,
225 | - if any of its dynamic prerequisites from a previous run or any of its static
226 | prerequisites is obsolete,
227 | - if the latest file corresponding to its siblings or itself is older than any
228 | of its dynamic prerequisites or static prerequisites.
229 |
230 | In all the other cases, it is assumed to be up-to-date (and so are all its
231 | siblings). Note that the last rule above says "latest" and not "earliest". While
232 | it might cause some obsolete targets to go unnoticed in corner cases, it allows
233 | for the following kind of rules:
234 |
235 | @verbatim
236 | config.h stamp-config_h: config.h.in config.status
237 | ./config.status config.h
238 | touch stamp-config_h
239 | @endverbatim
240 |
241 | A `config.status` file generally does not update header files (here
242 | `config.h`) if they would not change. As a consequence, if not for the
243 | `stamp-config_h` file above, a header would always be considered obsolete
244 | once one of its prerequisites is modified. Note that touching `config.h`
245 | rather than `stamp-config_h` would defeat the point of not updating it in
246 | the first place, since the program files would need to be rebuilt.
247 |
248 | Once all the static prerequisites of a target have been rebuilt, remake
249 | checks whether the target still needs to be built. If it was obsolete only
250 | because its prerequisites needed to be rebuilt and none of them changed, the
251 | target is assumed to be up-to-date.
252 |
253 | \subsection sec-rules How are targets (re)built?
254 |
255 | There are two kinds of rules. If any of the targets or prerequisites contains
256 | a `%` character, the rule is said to be generic. All the
257 | targets of the rule shall then contain a single `%` character. All the
258 | other rules are said to be specific.
259 |
260 | A rule is said to match a given target:
261 |
262 | - if it is specific and the target appears inside its target list,
263 | - if it is generic and there is a way to replace the `%` character
264 | from one of its targets so that it matches the given target.
265 |
266 | When remake tries to build a given target, it looks for a specific rule
267 | that matches it. If there is one and its script is nonempty, it uses it to
268 | rebuild the target.
269 |
270 | Otherwise, it looks for a generic rule that matches the target. If there are
271 | several matching rules, it chooses the one with the shortest pattern (and if
272 | there are several ones, the earliest one). It then looks for specific rules
273 | that match each target of the generic rule. All the prerequisites of these
274 | specific rules are added to those of the generic rule. The script of the
275 | generic rule is used to build the target.
276 |
277 | Example:
278 |
279 | @verbatim
280 | t%1 t2%: p1 p%2
281 | commands building t%1 and t2%
282 |
283 | t2z: p4
284 | commands building t2z
285 |
286 | ty1: p3
287 |
288 | # t2x is built by the first rule (which also builds tx1) and its prerequisites are p1, px2
289 | # t2y is built by the first rule (which also builds ty1) and its prerequisites are p1, py2, p3
290 | # t2z is built by the second rule and its prerequisite is p4
291 | @endverbatim
292 |
293 | The set of rules from Remakefile is ill-formed:
294 |
295 | - if any specific rule matching a target of the generic rule has a nonempty script,
296 | - if any target of the generic rule is matched by a generic rule with a shorter pattern.
297 |
298 | \section sec-compilation Compilation
299 |
300 | - On Linux, MacOSX, and BSD: `g++ -o remake remake.cpp`
301 | - On Windows: `g++ -o remake.exe remake.cpp -lws2_32`
302 |
303 | Installing remake is needed only if Remakefile does not
304 | specify the path to the executable for its recursive calls. Thanks to its
305 | single source file, remake can be shipped inside other packages and
306 | built at configuration time.
307 |
308 | \section sec-differences Differences with other build systems
309 |
310 | Differences with make:
311 |
312 | - Dynamic dependencies are supported.
313 | - For rules with multiple targets, the shell script is executed only once
314 | and is assumed to build all the targets. There is no need for
315 | convoluted rules that are robust enough for parallel builds. For generic
316 | rules, this is similar to the behavior of pattern rules from gmake.
317 | - As with redo, only one shell is run when executing a script,
318 | rather than one per script line. Note that the shells are run with
319 | option `-e`, thus causing them to exit as soon as an error is
320 | encountered.
321 | - The prerequisites of generic rules (known as implicit rules in make
322 | lingo) are not used to decide between several of them, which means that
323 | remake does not select one for which it could satisfy the dependencies.
324 | - Variables and built-in functions are expanded as they are encountered
325 | during Remakefile parsing.
326 | - Target-specific variables are not propagated, unless specifically enabled,
327 | since this causes non-deterministic builds.
328 |
329 | Differences with redo:
330 |
331 | - As with make, it is possible to write the following kind of rules
332 | in remake.
333 | @verbatim
334 | Remakefile: Remakefile.in ./config.status
335 | ./config.status Remakefile
336 | @endverbatim
337 | - If a target is already built the first time remake runs, it still
338 | uses the static prerequisites of rules mentioning it to check whether it
339 | needs to be rebuilt. It does not assume it to be up-to-date. As with
340 | redo though, if its obsolete status would be due to a dynamic
341 | prerequisite, it will go unnoticed; it should be removed beforehand.
342 | - Multiple targets are supported.
343 | - remake has almost no features: no checksum-based dependencies, no
344 | compatibility with job servers, etc.
345 |
346 | \section sec-limitations Limitations
347 |
348 | - If a rule script calls remake, the current working directory should
349 | be the directory containing Remakefile (or the working directory
350 | from the original remake if it was called with option `-f`).
351 | - As with make, variables passed on the command line should keep
352 | the same values, to ensure deterministic builds.
353 | - Some cases of ill-formed rules are not caught by remake and can
354 | thus lead to unpredictable behaviors.
355 |
356 | \section sec-links Links
357 |
358 | @see http://cr.yp.to/redo.html for the philosophy of redo and
359 | https://github.com/apenwarr/redo for an implementation and some comprehensive documentation.
360 |
361 | \section sec-licensing Licensing
362 |
363 | @author Guillaume Melquiond
364 | @version 0.16
365 | @date 2012-2024
366 | @copyright
367 | This program is free software: you can redistribute it and/or modify
368 | it under the terms of the GNU General Public License as published by
369 | the Free Software Foundation, either version 3 of the License, or
370 | (at your option) any later version.
371 | \n
372 | This program is distributed in the hope that it will be useful,
373 | but WITHOUT ANY WARRANTY; without even the implied warranty of
374 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
375 | GNU General Public License for more details.
376 |
377 | \section sec-internals Internals
378 |
379 | The parent remake process acts as a server. The other ones have a
380 | REMAKE_SOCKET environment variable that tells them how to contact the
381 | server. They send the content of the REMAKE_JOB_ID environment variable,
382 | so that the server can associate the child targets to the jobs that
383 | spawned them. They then wait for completion and exit with the status
384 | returned by the server. This is handled by #client_mode.
385 |
386 | The server calls #load_dependencies and #save_dependencies to serialize
387 | dynamic dependencies from .remake. It loads Remakefile with
388 | #load_rules. It then runs #server_mode, which calls #server_loop.
389 |
390 | When building a target, the following sequence of events happens:
391 |
392 | - #start calls #find_rule (and #find_generic_rule) to get the rule.
393 | - It then creates a pseudo-client if the rule has static dependencies, or
394 | calls #run_script otherwise. In both cases, a new job is created; the
395 | rule and the variables are stored into #jobs.
396 | - #run_script creates a shell process and stores it in #job_pids. It
397 | increases #running_jobs.
398 | - The child process possibly calls remake with a list of targets.
399 | - #accept_client receives a build request from a child process and adds
400 | it to #clients. It also records the new dependencies of the job into
401 | #dependencies. It increases #waiting_jobs.
402 | - #handle_clients uses #get_status to look up the obsoleteness of the
403 | targets.
404 | - Once the targets of a request have been built or one of them has failed,
405 | #handle_clients calls #complete_request and removes the request from
406 | #clients.
407 | - If the build targets come from a pseudo-client, #complete_request calls
408 | #run_script. Otherwise it sends the reply to the corresponding child
409 | process and decreases #waiting_jobs.
410 | - When a child process ends, #server_loop calls #finalize_job, which
411 | removes the process from #job_pids, decreases #running_jobs, and calls
412 | #complete_job.
413 | - #complete_job removes the job from #jobs and calls #update_status
414 | to change the status of the targets. It also removes the target files in
415 | case of failure.
416 | */
417 |
418 | #ifdef _WIN32
419 | #define WIN32_LEAN_AND_MEAN
420 | #define WINDOWS
421 | #endif
422 |
423 | #include
424 | #include
425 | #include
426 | #include