Skip to content
Request a Quote Request a Trial
Request a Quote Request a Trial

Copying CCL files to the private CCL directory

Question

As instructed, when I want to alter a public CCL file, I first make a copy of the file and place it in the private CCL directory. But now when I compile the CCL's in the private directory, I encounter a bunch of errors. I thought this was the recommended approach. What is the problem?

Synopsis

Copying CCL files to the private CCL directory

Solution

"Copying the file from your public to private CCL directory in order to edit it, is the recommended approach. The alternative would be to edit the CCL files directly in the public directory without ever copying them into the private CCL directory. This might cause additional problems and it will also be a problem as public CCLs are routinely overwritten with OSLO updates.

The problem is that some of the items in the public CCL file are now in conflict with the original public CCL file. The private CCL file needs to be edited in the following way:

First off, let's establish the typical contents of a CCL file:

  1. References to ""included"" files (#include...)
  2. Definition of global constants (#define...)
  3. A declaration of a command to be defined later (static cmd Enter_image_center_coordinates...)
  4. Global variables (variables defined outside of commands)
  5. Command definitions (cmd source...)
  6. Static command definitions (static void source_slice...)

Only some of these items can be repeated in a CCL file in the private directory. If you attempt to create doubles of some of these items in the private directory, an error message occurs during compilation of the CCLs.

As an alternative, here are specific suggestions as to how to re-write the contents of a CCL file for compilation in the private directory:

  1. Repeat as is. You may still need to have references to these "included" files
  2. If you use the exact same global constants, there is no reason to repeat these in the private CCL, but you can if you like.
  3. If you use the exact same functions, there is no reason to repeat these in the private CCL, but you can if you like.
  4. You cannot repeat these in the private CCL. Do not repeat any global variables that have already been defined in the public CCL. If you need to define global variables for the private form of the command, rename the command and rename the variables appropriately (source becomes my_source, and source_id becomes my_source_id, ...etc.)
  5. Command definitions are the crux of what you are intending to modify. Go ahead and change the definition of the command and it will supercede the same command compiled in the public directory.
  6. Some key command definitions are marked as "static" in the public directory. This is a form of protection. Commands marked static are crucial to the operation of the program and it is dangerous to make changes to them because the changes can be far-reaching. You have two options.
    • You can delete the word "static" in the public CCL. Then you can create another command of the same name in the private version of the CCL. NOTE: This is dangerous to do. It's equivalent to taking away a warning sign without abating the problem. Plus, there is no guarantee that the file will not be overwritten when OSLO is updated.
    • You can copy the command to the private directory, but rename it from source_slice to my_source_slice (it would be wise to change appropriate global variable definitions too)."