log inhelp

  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

BuildTools-Reference sc-server

This version was saved 14 years, 5 months ago View current version     Page history
Saved by Juan Pinzon
on October 29, 2009 at 4:29:09 pm
 

Usage

 

sc-server [target1 .. targetN] [--languages=LANG|-L] [--build=BUILD-NUMBER|-b] [--[no-]include-required|-r] [--project=PROJECT|-p] [--manifest=MANIFEST|-m] [--target=TARGET-PATH|-t] [--all|-a] [--[no-]symlink] [--mode=MODE|-M] [--clean] [--verbose] [--debug] [--help]

 

Synopsis

 

Builds one or more JavaScript bundles.

 

This tool is the primary entry point into the SproutCore build system to generate output suitable for deployment on your production servers.  Most of the time, you can invoke this tool with the simple form:

 

sc-server app-name -r

 

This will build your app to your build location (usually ./tmp/build) along with any required bundles.  This mode will auto-detect the installed languages in your application and build for all of them.  If you have a previous build in that location, it will be updated without doing a clean build.  Symlinks will be enabled in this mode if your build platform supports symlinks.

 

Most of the other options described here are mostly useful if you are using an automated build system and you need to specify options more exactly.  Aside from using the build options here, you can also customize your build extensively by modifying the Buildfile included in your project.  See the detailed discussion below for more information.  Usually you will want to provide most of your customization through the Buildfile since that will be picked up by sc-server for use during development as well.

 

Note that if you have multiple applications defined in your project (say you are building a suite or have a desktop and mobile version), you can also omit the list of targets altogether.  This will build every target in your project along with any required dependencies (unless you disable that behavior with --[no-]include-required).

 

Options

 

-a, --[no-]all If you do not name any targets, normally all bundles will be built except those with the "autobuild" option set to false in their configs.  Passing this option will build all targets, including those with autobuild turned off.
-L, --languages=en,fr...  Manually specifies the exact languages you want to build.  This will effect all bundles, including dependencies.  Normally the build system will autodetect the languages you have created.  This option overrides that behavior. 
-b, --build=NUMBER  Manually specifies the build number you want used for building.  You can either pass a single build number, which will be used for all bundles, or you can pass build numbers of each bundle using the format  "--build=sproutcore:1a23,contacts:3b42", etc.  If you specify an "all" build number, the number will be used for bundles not explicitly named on the command line.  Note that you can also name a build number for each bundle in your Buildfile. 
-r, --[no-]include-required Builds any dependent bundles with the targets you specifically named.  For simple build and deployment systems, this is usually the best option, though if you have an automated build system you may prefer to build each target independently and therefore disable this option. 
-p,--project=PROJECT Manually specifies the path to the project you are building from.  Normally sc-build expects your current working directory to be somewhere inside of the project you are building.  You can invoke the tool from anywhere, however, and use this option instead to specify the project directory.
-m, --manifest=MANIFEST Manually specifies the manifest file to use when building.  A manifest file describes all of the build actions required to build this particular project.  Normally a manifest is automatically generated as the first step of the build process, but you can override this by naming the manifest yourself.  You may want to do this, for example, if you generate the manifest and then tweak it before building.
-t, --target=TARGET-PATH Manually specifies the target directory to place build output.  Normally this is derived from the project's build_root config (default ./tmp/build).  You may want to use this if you are using an automated build system and you want all of your build output to go to a particular directory.
-d, --[no-]docs Builds documentation for your bundle in addition to building the bundle itself.  This uses the new sc-doc tool.  
--[no-]symlink Enables the use of symlinks.  If you use symlinks, then places where you need duplicate copies of a resource may simply symlink back to an original source.  This makes your built products smaller but it will not work when deployed on Windows machines and it makes it harder to strip out language directories.  The default for this mode is to leave symlinking turned OFF, but you can enable it if final package size is important to you. 
-M, --mode=MODE Manually specify the build mode you want to use.  Build modes swap in a different set of build options that may, for example, combine javascripts or not, minify or not, and so on.  The default build mode for sc-build is "production", which is usually the mode that you want. 
-c, --[no-]clean Cleans the build output (by removing the build directory) before doing a build.  The default behavior simply updates existing files that have changed, which is faster but it may at times leave old artifacts around (such as images you've since removed or renamed.)  Before you do a build destined for production, it is a good idea to always do a clean build. 
-v, --verbose Enables the verbose log level.  This is useful if you need to see exactly the steps performed during the build to ensure your options are working properly. 
--debug Enables debug log level.  This is useful if you are writing your own Buildfile or otherwise hacking the build tools 

 

In addition to the above options, the following deprecated options are supported for backwards compatibility: 

 

-e, --environment=MODE Same as the new --mode option.  This option name came originally from the build tools Rails heritage but it has been renamed to match the Buildfile build_mode option.
-l, --library=PROJECT Same as the new --project option.  "Libraries" were renamed "Projects" to match the terminology used in documentation.

 

Detailed Discussion

 

Provide any detailed documentation beyond  the synopsis above.  Any additional sections go here.

 

History

 

Added in SproutCore 1.0.

 

  

Comments (0)

You don't have permission to comment on this page.

Printable version