|--create (or -c)||
Use this if you already have a bigtop source file and want to make
a brand new app from it. Perhaps someone gave you a bigtop file, you
copied one from the examples directory of the bigtop distribution, or
you built one with tentmaker.
This will make an h2xs style path under the current directory for the app described in your bigtop file. It will even copy that bigtop file into the docs directory while it builds whatever you ask for.
Without this option, if the current directory looks like a bad place to build, a fatal error will result and you will have to use this option. A bad place to build is a place where building seems not to have happened before. If any of these are missing, then the directory is bad:
When create is in effect, the following bigtop config options affect the location of the initial build:
When create is not in effect, these config parameters are ignored WITH a warning.
|--new (or -n) App::Name style_info...||
See STYLES below for what style_info can be. (Hint: it depends on
which style you are using.)
Use this option to create a working application from scratch. If you only provide an app name, it will use a minimal bigtop specification. The resulting app will not run (or have any code in it). You must then augment the bigtop file with tentmaker or a text editor and regenerate to get a running app.
If you supply optional table names or provide data for a style, enough additional items will be added to the bigtop file to make a running app (except that you might need to build the database). Some of the extra items will be repeated for each model you request.
In either case, when bigtop finishes, there will be an App-Name subdirectory of the current directory. In it will be all the usual pieces describing an app. The bigtop file will be in the docs directory.
If you have a working sqlite in your path and you specified tables or used a style -n will also make an sqlite database called app.db in the build directory. As it will tell you, you can change to that directory and start the app immediately.
If you dont have sqlite, a message will explain what to do to start the app. Mostly this boils down to changing into the new build directory, creating a database called app.db, and running app.server with the proper flags for your database engine.
This flag uses the default bigtop file from Bigtop::ScriptHelp (which you can see by examining examples/default.bigtop in the distrubution). If you like, you may override that default. To do so, copy examples/default.bigtop to either bigtopdef in the directory from which you plan to run bigtop -n, or to .bigtopdef in your home directory. Edit the file to your hearts content.
The result must be a valid bigtop file, with one exception. The file you create will be used as a template toolkit template. But, only three things are available for subsitution:
For example see examples/def.bigtop.tt.
If you have a ./bigtopdef or ~/.bigtopdef, but dont want to use it for a particular instance, set the BIGTOP_REAL_DEF enivornment variable in your shell.
|--add (-a )||
If you have an existing bigtop file and want to add tables and their
controllers to it, use this option like this:
See STYLES below for how to specify table relationships.
This option reads an existing file.bigtop and adds tables and controllers to it, before doing an all build. (If you dont want an all build, use the same options with tentmaker.)
Any new tables will be created. Whether existing tables are updated depends on you style.
Note that this option may disturb comments and whitespace in your original. It uses Bigtop::Deparser, which cannonicalizes the whitespace. Basically extraneous whitespace is removed (and indenting is regularized). When new lines are removed, subsequent comments drift down in the revised file.
Revision control is always a good idea. It is especially important here. Make sure file.bigtop is commited to your revision control system prior to running bigtop in add mode.
|--keep_inline (or -k)||Normally, this script removes all traces of the _Inline directory it used while building your app. Use this option if you want to save a microscopic amount of time on each regeneration or if you have an incurable curiosity.|
|--style (or -s)||Defaults to Kickstart. This can be the name of any Bigtop::ScriptHelp::Style:: module. These styles control how your command line args, and standard input, turn into bigtop descriptions. See the docs for you style to see what input is legal and how it is treated.|
In addition to the flags that do useful things, there are help flags:
--help or -h Prints a multi-line usage message showing all the options. --pg_help and --mysql_help Print advice on how to start your app.server with a Postgres or MySQL database instead of sqlite. This includes instructions on creating and building the database, as well as flags app.server needs in order to reach that database.
This section used to explain ASCII art, which was the original style of command line input. Since then, that code has been factored out. The original style is now called the kickstart style, or more precisely Bigtop::ScriptHelp::Style::Kickstart and is still the default. See its docs for a description of ASCII art.
You may explicitly choose the original style:
bigtop -n|-a -s Kickstart ascii_art
But, you may omit -s to get Kickstart by default. Further, you can replace Kickstart with any module in the Bigtop::ScriptHelp::Style:: namespace. For example:
bigtop -n|-a -s Pg8Live dbi:Pg:dbname=yourdb user pass [schema]
Again, see the docs for your style to see what command line parameters to use.
Phil Crow <email@example.com>
Copyright (C) 2005-7 by Phil Crow
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.6 or, at your option, any later version of Perl 5 you may have available.
|perl v5.20.3||BIGTOP (1)||2016-04-03|