solution found; was: Re: [MITgcm-support] no -mpi option forgenmake2

[m. r. schaferkotter]

ed:

i simply moved the files (below) out of the way and redid the entire 
build process with success.


>> ? eesupp/src/exch_uv_agrid_xy.rl.F
>> ? eesupp/src/exch_uv_agrid_xy.rs.F
>> ? eesupp/src/exch_uv_agrid_xyz.rl.F
>> ? eesupp/src/exch_uv_agrid_xyz.rs.F

seems to me the solution to all of this 'should' be in cvs rather than 
in the make scheme.

i didn/t really change the distribution on my end, so from a user/s 
standpoint i was depending on
cvs to manage the distribution. isn/t that what cvs is for?

so we move on.

thanx to all.

m.r.

On Wednesday, August 11, 2004, at 11:35 AM, Ed Hill wrote:

>
> On Wed, 2004-08-11 at 12:14, m. r. schaferkotter wrote:
>> chris and ed:
>>
>> first the cvs update is on a lintel system (not Mac-osx). i/m updating
>> my copy at work (lintel) and home is (OSX).
>>
>> did exactly as ed suggested:
>>
>>   'cvs -q up -d -P' in the $MITGCM_ROOT
>>
>> but notice:
>>
>> [me at mach MITgcm]$ cvs -q up -d -P
>> ? eesupp/src/exch_uv_agrid_xy.rl.F
>> ? eesupp/src/exch_uv_agrid_xy.rs.F
>> ? eesupp/src/exch_uv_agrid_xyz.rl.F
>> ? eesupp/src/exch_uv_agrid_xyz.rs.F
>
>
> Hi Michael,
>
> Theres the problem!  CVS doesn't know what to do with these
> exch_uv_agrid* files (because they are template-generated) so it leaves
> them be.  And, because the Makefile has been updated and no longer
> reflects the older templating process, "make clean" doesn't know what 
> to
> do with them, either!
>
> So you've clearly identified a case where:
>
>   cd $MITGCM_ROOT  &&  cvs -q up -d -P
>   cd $YOUR_BUILD_DIR
>   make CLEAN  &&  make makefile  &&  make depend  &&  make
>
> isn't sufficient.  Thats progress!  And I think I owe you a beer.
>
> OK, so the general solution here is to delete all the files and
> directories that "cvs up" tags with a leading question mark.  That way,
> you would get rid of any such stale files/dirs.  You'd also loose 
> things
> that you've modified but not checked into CVS--which may be a really 
> bad
> idea.
>
> And I don't see how we could (or for that matter, *should*) try to 
> write
> Makefiles smart enough to deal with this sort of situation.  I think 
> the
> best advice what I originally said which is: please get a clean, fresh
> check-out!
>
> Ed