`configure' recognizes the following options to control how it operates.
`configure' recognizes the following options to control how it
operates.
`--help'
`-h'
Print a summary of the options to `configure', and exit.
Print a summary of all of the options to `configure', and exit.
`--help=short'
`--help=recursive'
Print a summary of the options unique to this package's
`configure', and exit. The `short' variant lists options used
only in the top level, while the `recursive' variant lists options
also present in any nested packages.
`--version'
`-V'
Print the version of Autoconf used to generate the `configure'
script, and exit.
`--cache-file=FILE'
Enable the cache: use and save the results of the tests in FILE,
traditionally `config.cache'. FILE defaults to `/dev/null' to
disable caching.
`--config-cache'
@@ -223,15 +267,25 @@ an Autoconf bug. Until the bug is fixed
`--quiet'
`--silent'
`-q'
Do not print messages saying which checks are being made. To
suppress all normal output, redirect it to `/dev/null' (any error
messages will still be shown).
`--srcdir=DIR'
Look for the package's source code in directory DIR. Usually
`configure' can determine that directory automatically.
`--prefix=DIR'
Use DIR as the installation prefix. *Note Installation Names::
for more details, including other options available for fine-tuning
the installation locations.
`--no-create'
`-n'
Run the configure checks, but stop before creating any output
files.
`configure' also accepts some other, not widely useful, options. Run
`configure --help' for more details.
TODO
➞
Show inline comments
new file 100644
1. Create a CLI interface for distren
command: distren
args: -i infile.tar.bz2 -o outfile.tar.bz2
action: submits and blocks and retreives result of rendering the contents of infile.tar.bz2. Should currently just call stub functions.
2. Design of stubs in distren CLI:
Stub for submitting file to a server
Stub for waiting for server
3. Design of stubs in distrend:
Stub for getting info from the tarball/validifying the tarball. Read distren-job.xml, a file in the tarball, to find out 1. which rendering system to use (that system, e.g. blender/povray, can read more specifics, such as name of file to pass to blender and frames. Options common between different systems will be handled in common as best as possible)
Stub for unpacking file
Stub for calling subsystem's action that does the rendering
Stub for submission of new jobs to be distributed (a subsystem rendering a file with multiples frames should generate a subjob for each frame)
Stub for publishing file and constructing job description so that the job can be shared