[MITgcm-devel] genmake2 fails with netcdf on SUN

[Martin Losch]

Happy New Year everyone!

I am sorry to have set an aggressive tone. This make and awk issue on 
SunOS is a pain in the neck. I keep forgetting that it is an issue, so 
that whenever I try to show someone here how great the MITgcm works, it 
doesn't even compile because of problems with make and awk! That's why 
my "bug report" yesterday wasn't particularily helpful: I needed to let 
off some steam.
My general feeling is that Sun Shell tools (such as make and awk) do 
not always work properly even with the correct syntax. I have made this 
observation many times (independent of the MITgcm), so I would think 
that for Suns
>  "with other makes we abuse you a bit first and then
>     try and fix the problem if we can"
is a good motto (o:

It is even worse that I cannot let anyone have access to our systems, 
but I can't help it. It's tough enough to get (a working!) access to 
our machines when you are an employee here, but that's a different 
story...

Before I sent this email yesterday, I had tried to reproduce the 
problems I had yesterday on slough.mit.edu, where in principle the 
operating system should be similar to what I have, but I couldn't get 
genmake2 to recognize the netcdf libraries correctly. This may have 
many reasons, the most likely one is that with the current f77 (Forte 
Workshop 6.x) the libraries simply don't work because they have been 
compiled with Forte 5 compilers?
Ed, could you please try to make the MITgcm compile with netcdf on 
SunOS (slough.mit.edu or fjord.mit.edu) with the build options file 
"sunos_sun4u_f77"? It will probably take you 5min as opposed to 1 hour, 
if I try it again. The netcdf libraries etc are in 
/usr/local/netcdf/include and /usr/local/netcdf/lib.
I'll will then try to reproduce my probelms with awk and make on 
slough.mit.edu.

For now I can say this: with /usr/ccs/bin/make, which seems to be the 
only make on our system other than gmake (GNU) and dmake (Sun's 
"distributed make") genmake2 stalls will processing the following 
line(s) in pkg/mnc/Makefile:
> MNC_CW_READWRITE_RS.F: mnc_cw_readwrite.template
> 	cat $< | sed -e 's/RX/RS/g' | sed -e 's/__V/_RS/g' > $@
As far as I can see, this line is syntactically prefectly okay, but 
somehow "$<" is not expanded, so that the following line is actually 
executed:
 >>> cat | sed -e 's/RX/RS/g' | sed -e 's/__V/_RS/g' > 
MNC_CW_READWRITE_RS.F
and that can't work.

That's all I can see now. Similar things happend within genmake2 with 
awk (some shell variables/macros where not expanded correctly), but 
I'll try to reproduce that in some more detail later.

Martin

On Jan 4, 2005, at 10:02 PM, Ed Hill wrote:

> On Tue, 2005-01-04 at 14:15 -0500, Alistair Adcroft wrote:
>> Martin Losch wrote:
>>> The probelm can be fixed by specifying MAKE=gmake. What do I have to
>>> conclude? On some Sun-Systems make is f***ed-up and on some others it
>>> isn't? I would be nice, if the makefiles and scripts would be truly
>>> platform independent and that one doesn't have to rely on gmake and 
>>> gawk
>>> by default! The default make on my system is unfortunately
>>
>> The last I heard on this we had agreed that we would be platform
>> independent. Please correct me if I'm wrong.
>
>
> Hi Alistair and Martin,
>
> You're close.  The actual policy is:
>
>    "with other makes we abuse you a bit first and then
>     try and fix the problem if we can" [1]
>
>
> Martin's bug reports are not particularly helpful.  They're full of
> rambling complaints but short on detail that I can use to improve
> things.  Since I am not allowed to have any access to the Suns that
> Martin is using, the best that we can do is:
>
>   1) write custom optfiles for each machine that
>      you (Martin) are using
>
>   2) either:
>      a) *VERIFY* that each of those custom optfiles
>         really does exactly what you want, or
>      b) write a *precise* bug report saying exactly
>         why its impossible to generate such an optfile
>
>   3) send everything from (2a) and (2b) to me and I'll
>      do my best to improve things (that is, abstract
>      the settings and behavior so that we minimize the
>      need for custom optfiles)
>
> Ed
>
> [1] http://mitgcm.org/pipermail/mitgcm-devel/2004-September/001007.html
>
> -- 
> Edward H. Hill III, PhD
> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
>              Cambridge, MA 02139-4307
> emails:  eh3 at mit.edu                ed at eh3.com
> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> phone:   617-253-0098
> fax:     617-253-4464
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel