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. |
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. |
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. |
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. |
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. |
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. |
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.) |
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.) |
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. |