MECCA User Documentation

MECCA Usage Examples

Modifying an existing PA (Primary Application)

What you type(on a single line)	What it does
mkdir <name of new directory>	creates directory for PA source code
cd <name of new directory>	puts you in the new directory
mecca --copy <name of PA, e.g., pa4240>	checks out PA's current source code
mecca --dev	builds PA and places it on the Z index page (It is not a bad idea to verify that a PA builds before you add your own changes.)
nedit <whatever file(s)> &	make your changes
mecca --dev	test your changes on the Z index page
mecca --diff	to double check your changes
mecca --commit	commit your changes which will update the source code and production executable with your changes. You will be prompted for confirmation and a description of your changes.

Creating a new PA (Primary Application)

What you type(on a single line)	What it does
cd <name of empty directory>	puts you in an empty directory
mecca --newpa	gets a new PA number so that you create a new program (Run this only once. After that just use mecca --dev)
nedit <whatever file(s)> &	make your changes
mecca --dev	test your new application on the Z index page
mecca --commit	commit your changes which will update the source code and production executable with your changes. You will be prompted for confirmation and a description of your changes.

Modifying an existing SA (Secondary Application)

What you type(on a single line)	What it does
mkdir <name of new directory>	creates directory for SA source code
cd <name of new directory>	puts you in the new directory
mecca --copy <name of SA, e.g., sa4014>	checks out SA's current source code
mecca --dev	builds SA and places it on the D7 SA testing page (It is not a bad idea to verify that an SA builds before you add your own changes.)
nedit <whatever file(s)> &	make your changes
mecca --dev	test your changes using the D7 SA testing page (You must use a PA (Primary Application) to launch your SA.)
mecca --diff	to double check your changes
mecca --commit	commit your changes which will update the source code and production executable with your changes. You will be prompted for confirmation and a description of your changes.

Creating a new SA (Secondary Application)

What you type(on a single line)	What it does
cd <name of empty directory>	puts you in an empty directory
mecca --newsa	gets a new SA number so that you create a new program (Run this only once. After that just use mecca --dev)
nedit <whatever file(s)> &	make your changes
mecca --dev	test your new application using the D7 SA testing page (You must use a PA (Primary Application) to launch your SA.)
mecca --commit	commit your changes which will update the source code and production executable with your changes. You will be prompted for confirmation and a description of your changes.

Modifying an existing Service

What you type(on a single line)	What it does
mkdir <{name of service}>	creates directory for service source code
cd <{name of service}>	puts you in the new directory
mecca --copy <{name of service}>	checks out service's current source code
mecca --dev	builds service (It is not a bad idea to verify that a service builds before you add your own changes.)
nedit <whatever file(s)> &	make your changes
mecca --dev	test your changes
mecca --diff	to double check your changes
mecca --commit	commit your changes which will update the source code and production executable with your changes. You will be prompted for confirmation and a description of your changes.

Creating a new Service

What you type(on a single line)	What it does
mkdir <{name of service}>	creates directory for service source code
cd <{name of service}>	puts you in development directory
mecca --newcs {service name}	creates a new service project (Run this only once. After that just use mecca --dev)
nedit <whatever file(s)> &	make your changes
mecca --dev	test your new service
mecca --commit	commit your changes which will update the source code and production executable with your changes. You will be prompted for confirmation and a description of your changes.

MECCA Reference

**Commands**
Command	Description
`mecca --copy {project}`	Checkout the code for a program when run in empty directory. When run in non-empty directory will update current directory with changes commited to MECCA since last copy done in the current directory.
`mecca --uncopy`	Inverse of `--copy`. Checks for uncommited changes in the current directory and if the user confirms then removes all files from the current directory. This leaves the directory ready for another `mecca --copy`.
`mecca --update`	Must be run in a directory populated by a previous mecca --copy. Will update current directory with changes commited to MECCA since last copy done in the current directory.
`mecca --diff`	Must be run in a directory populated by a previous mecca --copy. Will display differences from what is in MECCA repository, i.e., your changes.
`mecca --dev[elopment] [{project}]`	Compile a program and place it on the Z index page (for PAs) or the D7 SA testing page (for SAs). In the case of a service or library, the item is merely built in the working directory.
`mecca {--commit} {--deletes_allowed} [{project}]`	Commit and release modified application code. To remove files one must add --deletes_allowed. When --deletes_allowed is present MECCA will remove from the repository any files removed from the working directory.
`mecca --rebuild {project}`	recompiles and releases a program, e.g., if a library changes
`mecca --retreat {project}`	backs out changes to a program or library (MECCA will prompt for the old version to be made the current version.)
`mecca --newpa`	creates a new primary application (MECCA will assign a PA number.)
`mecca --newsa`	creates a new secondary application (MECCA will assign an SA number.)
`mecca --newcs {service}`	creates a new (central) service (The user must supply an available name.)
`mecca --newlib ul_{library}`	creates a new user library (The user must supply an available name starting with ul_.)
`mecca --history {project}`	displays a history of changes made to this project
`mecca --showinfo {project}`	displays information about a program, e.g., its description and keeper
`mecca --info {project}`	changes information about a program, e.g., its description and keeper
`mecca --subscribe {project}`	subscribes the user to emails of code changes and program crashes
`mecca --unsubscribe {project}`	unsubscribes the user from emails of code changes and program crashes
`mecca --make {target}`	Build the whole program/library or just a part, i.e., target. Target is terminology from make, e.g., `mecca --make foo.o`. This does not release the changes or even place them on the Z index page or the D7 SA testing page. One might find `mecca --make foo.E` useful, as this will run foo.cpp through the preprocesser and leave the results in foo.E. This can be helpful to track down issues caused by poor choices in header files, e.g., "`#define const // turn off const`" in some user library header file. (There are additional options to make including clean and sterile.)

**Files**
File	Description
depends.opt	One for each program and contained in CVS with each program's source code. Developers specify which libraries a program needs in this file. It is one library per line. A library is specified by its name, e.g., ul_clib. One can use a test library by giving a full pathname, e.g., /export/home1/hendricks/cns/mecca/uls/ul_clib. Available user libraries are documented at https://www-ad.fnal.gov/help/#ulib. The "ul_" prefix is ommitted in the list but required by MECCA.
options.opt	One for each program and contained in CVS with each program's source code. Used to configure additional information about a program/library, e.g., whether or not a library should be built as shared library. Most users should leave this alone.
abstract.txt	Services can/should have an abstract file with some basic information about the service. This abstract is published to the web, e.g., MECCA's abstract. The abstract.txt file is commited into MECCA and the HTML file is generated from it and published.
build_results.txt	output of most recent build (This file should not be committed into MECCA.)
mecca_version_info.cpp	auto-generated by MECCA during a build and supports embedded version information
history.txt	one for each program which contains the history of changes to this project (This file is no longer updated by MECCA and should be ignored.)

**Targets**
Target	Description
*.E	MECCA can prepare a post preprocessor version of any .cpp file, so long as a the item is not using a custom Makefile. For example, to make a post preprocessor version of main.cpp, execute "mecca --make main.E". The .E extension is used because that is the gcc option used to simply run the preprocessor. Making a *.E file can help diagnose build issues that result from challenging use of the preprocessor, e.g., #defineing const to nothing.

Security, Privacy, Legal