Mike Gurnis wrote:

> Thanks, an additional clarification:
>
>
> "make" lust in the directory the change to the C code was made, for  
> example in
> lib/Common? Or, "make" in this directory as well as in /lib and then in
> /CitcomS-2.x.x?
>
>

For CitcomS, "make" just in the directory where the change was made 
would be enough (because CitcomS makes liberal use of shared libraries).

In general, this really depends upon the project and how the 'Makefile's 
and libraries are structured. Sometimes, you have to be in a parent 
directory for 'make' to have any effect on the final exectuable... or 
for 'make' to work at all.

--Leif

Thanks, an additional clarification:

On May 4, 2006, at 10:30 AM, Leif Strand "Roundup Issue Tracker" wrote:

>
> Leif Strand <leif@geodynamics.org> added the comment:
>
> I just wrote-up issue32 ("'make install' should be optional").  I  
> think, once it
> is fixed for CitcomS, everything will behave as expected.  Users  
> will no longer
> have to think about "--prefix" and "installing" the software.  They  
> can build
> everything under the CitcomS-2.x.x source/build directory, and run  
> executables
> directly from there.  They can effect changes to the C/C++ source  
> by simply
> typing "make".

"make" lust in the directory the change to the C code was made, for  
example in
lib/Common? Or, "make" in this directory as well as in /lib and then in
/CitcomS-2.x.x?

> Changes to Python won't require typing "make" at all.
>
> _____________________________________________________
> Roundup issue tracker <issue_tracker@geodynamics.org>
> <http://geodynamics.org/roundup/issues/issue28>
> _____________________________________________________
>
>

I just wrote-up issue32 ("'make install' should be optional").  I think, once it
is fixed for CitcomS, everything will behave as expected.  Users will no longer
have to think about "--prefix" and "installing" the software.  They can build
everything under the CitcomS-2.x.x source/build directory, and run executables
directly from there.  They can effect changes to the C/C++ source by simply
typing "make".  Changes to Python won't require typing "make" at all.

Now I understand about the directories being made by the make process. This is
obviously a great idea.

Now that I understand it, I think that this is a great idea. I think that there
might be a minor bug. 

When I did the configuration, I did the following:

cd CitcomS-2.0.2
./configure -- prefix=$HOME

Now go into CitcomS-2.0.2/visual and look at the three files, visFull.net, etc.
Inside of these files, the system has created paths such as:
/User/gurnis/share/CitcomS/visual/OpenDX/Macro/CitcomSTemperature.net

however, I think that the path should be:
/User/gurnis/CitcomS-2.0.2/visual, etc.

The OpenDX scripts are actually generated from templates during "make" -- that's
why they have 'gurnis' in them.  I did this so that users wouldn't have to set
the environment variable DXMACROS.

We may need an easy way to generate the scripts by themselves, in case the user
wants to do visualization on a different machine (i.e., their workstation).

Regarding the opendx scripts that are distributed under CitcomS-2.0.2/visual,
specifically the scripts called visFull.net and (probably) visRegional.net
several changes are needed for general purpose utility. First, the path to
"subroutines" within these *.net files have absolute locations (in fact, the
locations are tied to user gurnis). Need to bring in a relative path based on
presumably an environment variable. In addition, most of the other *.net and
*.cfg files should be placed under the OpenDXMacro directory. 

Changes are probably also needed for the manual. Specifically, in Chapter 4, the
needing "Postprocessing in a Non-Cluster Environment" is ambiguous because this
section also refers to the case when all of the files are located in a single
directory.