5 Permission is hereby granted, free of charge, to any person obtaining
6 a copy of this software and associated documentation files (the
7 "Software"), to deal in the Software without restriction, including
8 without limitation the rights to use, copy, modify, merge, publish,
9 distribute, sublicense, and/or sell copies of the Software, and to
10 permit persons to whom the Software is furnished to do so, subject to
11 the following conditions:
13 The above copyright notice and this permission notice shall be included
14 in all copies or substantial portions of the Software.
16 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
17 KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
18 WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
19 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
20 LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
21 OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
22 WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
30 The C<cons> command is usually invoked from the root of the build tree. A
31 F<Construct> file must exist in that directory. If the C<-f> argument is
32 used, then an alternate F<Construct> file may be used (and, possibly, an
33 alternate root, since C<cons> will cd to F<Construct> file's containing
36 If C<cons> is invoked from a child of the root of the build tree with
37 the C<-t> argument, it will walk up the directory hierarchy looking for a
38 F<Construct> file. (An alternate name may still be specified with C<-f>.)
39 The targets supplied on the command line will be modified to be relative
40 to the discovered F<Construct> file. For example, from a directory
41 containing a top-level F<Construct> file, the following invocation:
46 is exactly equivalent to:
48 % cons libfoo/subdir/target
50 If there are any C<Default> targets specified in the directory hierarchy's
51 F<Construct> or F<Conscript> files, only the default targets at or below
52 the directory from which C<cons -t> was invoked will be built.
54 The command is invoked as follows:
56 cons <arguments> , <construct-args>
58 where I<arguments> can be any of the following, in any order:
64 Build the specified target. If I<target> is a directory, then recursively
65 build everything within that directory.
69 Limit the F<Conscript> files considered to just those that match I<pattern>,
70 which is a Perl regular expression. Multiple C<+> arguments are accepted.
74 Sets I<name> to value I<val> in the C<ARG> hash passed to the top-level
79 Show command that would have been executed, when retrieving from cache. No
80 indication that the file has been retrieved is given; this is useful for
81 generating build logs that can be compared with real build logs.
85 Disable all caching. Do not retrieve from cache nor flush to cache.
89 Build dependencies in random order. This is useful when building multiple
90 similar trees with caching enabled.
94 Synchronize existing build targets that are found to be up-to-date with
95 cache. This is useful if caching has been disabled with -cc or just recently
96 enabled with UseCache.
100 Enable dependency debugging.
104 Use the specified file instead of F<Construct> (but first change to
105 containing directory of I<file>).
109 Show a help message local to the current build if one such is defined, and
114 Keep going as far as possible after errors.
118 Read override file I<file>.
122 Show construction products in specified trees. No build is attempted.
126 Show construction products and associated actions. No build is attempted.
130 Show products and where they are defined. No build is attempted.
134 Make the build quiet. Multiple C<-q> options may be specified.
136 A single C<-q> options suppress messages about Installing and Removing
139 Two C<-q> options suppress build command lines and target up-to-date
144 Remove construction products associated with <targets>. No build is
149 Search for files in I<repos>. Multiple B<-R> I<repos> directories are
150 searched in the order specified.
154 Use the sig::<pkg> package to calculate. Supported <pkg> values
155 include "md5" for MD5 signature calculation and "md5::debug" for debug
156 information about MD5 signature calculation.
158 If the specified package ends in <::debug>, signature debug information
159 will be printed to the file name specified in the C<CONS_SIG_DEBUG>
160 environment variable, or to standard output if the environment variable
165 Traverse up the directory hierarchy looking for a F<Construct> file,
166 if none exists in the current directory. Targets will be modified to
167 be relative to the F<Construct> file.
169 Internally, C<cons> will change its working directory to the directory
170 which contains the top-level F<Construct> file and report:
172 cons: Entering directory `top-level-directory'
174 This message indicates to an invoking editor (such as emacs) or build
175 environment that Cons will now report all file names relative to the
176 top-level directory. This message can not be suppressed with the C<-q>
181 Show C<cons> version and continue processing.
185 Show C<cons> version and exit.
189 Write all filenames considered into I<file>.
193 Show a help message similar to this one, and exit.
197 And I<construct-args> can be any arguments that you wish to process in the
198 F<Construct> file. Note that there should be a B<-,-> separating the arguments
199 to cons and the arguments that you wish to process in the F<Construct> file.
201 Processing of I<construct-args> can be done by any standard package like
202 B<Getopt> or its variants, or any user defined package. B<cons> will pass in
203 the I<construct-args> as B<@ARGV> and will not attempt to interpret anything
206 % cons -R /usr/local/repository -d os=solaris +driver -,- -c test -f DEBUG
208 would pass the following to cons
210 -R /usr/local/repository -d os=solaris +driver
212 and the following, to the top level F<Construct> file as B<@ARGV>
216 Note that C<cons -r .> is equivalent to a full recursive C<make clean>,
217 but requires no support in the F<Construct> file or any F<Conscript>
218 files. This is most useful if you are compiling files into source
219 directories (if you separate the F<build> and F<export> directories,
220 then you can just remove the directories).
222 The options C<-p>, C<-pa>, and C<-pw> are extremely useful for use as an aid
223 in reading scripts or debugging them. If you want to know what script
224 installs F<export/include/foo.h>, for example, just type:
226 % cons -pw export/include/foo.h
228 =head1 Selective builds
230 Cons provides two methods for reducing the size of given build. The first is
231 by specifying targets on the command line, and the second is a method for
232 pruning the build tree. We'll consider target specification first.
235 =head2 Selective targeting
237 Like make, Cons allows the specification of ``targets'' on the command
238 line. Cons targets may be either files or directories. When a directory is
239 specified, this is simply a short-hand notation for every derivable
240 product-,-that Cons knows about-,-in the specified directory and below. For
243 % cons build/hello/hello.o
245 means build F<hello.o> and everything that F<hello.o> might need. This is
246 from a previous version of the B<Hello, World!> program in which F<hello.o>
247 depended upon F<export/include/world.h>. If that file is not up-to-date
248 (because someone modified F<src/world/world.h)>, then it will be rebuilt,
249 even though it is in a directory remote from F<build/hello>.
255 Everything in the F<build> directory is built, if necessary. Again, this may
256 cause more files to be built. In particular, both F<export/include/world.h>
257 and F<export/lib/libworld.a> are required by the F<build/hello> directory,
258 and so they will be built if they are out-of-date.
264 then only the files that should be installed in the export directory will be
265 rebuilt, if necessary, and then installed there. Note that C<cons build>
266 might build files that C<cons export> doesn't build, and vice-versa.
271 In conjunction with target selection, B<build pruning> can be used to reduce
272 the scope of the build. In the previous peAcH and baNaNa example, we have
273 already seen how script-driven build pruning can be used to make only half
274 of the potential build available for any given invocation of C<cons>. Cons
275 also provides, as a convenience, a command line convention that allows you
276 to specify which F<Conscript> files actually get ``built''-,-that is,
277 incorporated into the build tree. For example:
281 The C<+> argument introduces a Perl regular expression. This must, of
282 course, be quoted at the shell level if there are any shell meta-characters
283 within the expression. The expression is matched against each F<Conscript>
284 file which has been mentioned in a C<Build> statement, and only those
285 scripts with matching names are actually incorporated into the build
286 tree. Multiple such arguments are allowed, in which case a match against any
287 of them is sufficient to cause a script to be included.
289 In the example, above, the F<hello> program will not be built, since Cons
290 will have no knowledge of the script F<hello/Conscript>. The F<libworld.a>
291 archive will be built, however, if need be.
293 There are a couple of uses for build pruning via the command line. Perhaps
294 the most useful is the ability to make local changes, and then, with
295 sufficient knowledge of the consequences of those changes, restrict the size
296 of the build tree in order to speed up the rebuild time. A second use for
297 build pruning is to actively prevent the recompilation of certain files that
298 you know will recompile due to, for example, a modified header file. You may
299 know that either the changes to the header file are immaterial, or that the
300 changes may be safely ignored for most of the tree, for testing
301 purposes.With Cons, the view is that it is pragmatic to admit this type of
302 behavior, with the understanding that on the next full build everything that
303 needs to be rebuilt will be. There is no equivalent to a ``make touch''
304 command, to mark files as permanently up-to-date. So any risk that is
305 incurred by build pruning is mitigated. For release quality work, obviously,
306 we recommend that you do not use build pruning (it's perfectly OK to use
307 during integration, however, for checking compilation, etc. Just be sure to
308 do an unconstrained build before committing the integration).
319 <title>Command-Line Options</title>
330 <title>Getting at Command-Line Arguments</title>
341 <title>Selective Builds</title>
354 <title>Build Pruning</title>
367 <title>Overriding Construction Variables</title>