[MITgcm-devel] Re: [Fwd: Re: latest genmake2 variant]

[Jean-Michel Campin]

Hi Jean,

I was not able to reproduce the former Pb (Feb 15 modif of
genmake2) and I don't remember which platform Constantinos
and me were trying at that time.

My impression is that commenting out the line to invalidate 
previous default dependencies (as it was before your changes,
and most likely, Ed commented it out to work on Sun:
v.1.101 check-in comments (Sep 2004):
> o use older-style make syntax
>   - works with Gnu make and Sun make     )
is not hurting too much, and we could follow this route,
unless someone has a better idea ?

Cheers,
Jean-Michel

On Mon, Nov 10, 2008 at 07:36:56AM -0600, Jean Utke wrote:
> Hi Martin, Jean-Michel,
> 
> I don't have a  solaris box where I could try this.
> I did a little bit of digging and see the following issues here.
> There was a change on Feb/15 that introduced a .F.o 
> rule by Jean-Michel. This is an alternative path to
> what in the comment above is listed as the  normal path:
> .F - .$FS - .o
> In the change comment it says that the new .F.o rule
> is  (for source files with no "#include" (such as port_rand.F);
> otherwise, default ignores FOPTIM and just uses FFLAGS.)
> 
> When I made my changes it was my understanding that  ALL  .F and .F90
> files should be funneled through  the explicit preprocessing step.
> When I look at the out of the Makefile prior to my change I find however
> it also creates
> port_rand.f by the following command:
> cat port_rand.F | ../../../tools/set64bitConst.sh |  cpp  -traditional
> -P -DWORDLENGTH=4 -DHAVE_SYSTEM -DHAVE_FDATE -DHAVE_ETIME -DHAVE_CLOC
> -DHAVE_SETRLSTK -DHAVE_SIGREG -DHAVE_STAT 
> -I/usr/local/pkg/netcdf/include > port_rand.f
> and then:
> ifort -132 -r8 -i4 -w95 -W0 -WB -convert big_endian -assume byterecl 
> -O0 -g -align -c port_rand.f
> In other words it bypasses the explicit .F.o rule for the file the
> change comment mentions as the rational e for
> introducing it - at least in my environment. 
> 
> The question I am not sure how to answer is:
> A: Shouldn't really all .F and .F90 files go through  consistent
> preprocessing steps?
>      if yes, then any relevant built-in  rules  should be nullified and
> there should not
>      be a direct .F.o rule
> B: Normally I would argue to not rely on any built in rules anyway but
> there may
>     be environments where you have to?
> 
> 
> Jean
> 
> 
> Martin Losch wrote:
> > Sorry, I sent the last email without looking very closely at the make
> > results:
> > 1. I attached another make.log, where I executed "make -dd" (more
> > debugging information). It seems that make tries to build according to
> > a rule .F.o which we do not have.
> > 2. I found that in the Makefile a line is commented in, that used to
> > be commented out (line 2682):
> >> ## This nullifies any default implicit rules concerning these two
> >> file types:
> >> ## %.o : %.F
> > when I comment out "%.o : %.F" make works. And this is also one of the
> > changes of the last check-in, diff -r 1.175 genmake2
> >> 2598c2685
> >> < ## %.o : %.F
> >> ---
> >> > %.o : %.F
> >
> >
> > Martin
> >
> > On 10 Nov 2008, at 09:21, Martin Losch wrote:
> >
> >> Hi there,
> >>
> >> here they come. It looks like only the C-files are compiled. When I
> >> do "make gad_grad_x.o" (or any other object that is build from a *.F
> >> file), then I don't get anything, any response, not even a "target is
> >> up to date. With gmake it works!
> >>
> >> So I could fix the opt-files for sunos (make/gmake has been a problem
> >> in the past, so has awk/gawk), but guess it's better to figure out,
> >> why make is not picking up the dependency/decides not to compile
> >> anything.
> >>
> >> It's difficult for me to help, because the changes to genmake2 are so
> >> many. I would be nice to have a genmake2 that could incrementally
> >> modify (following your instructions), or maybe you have a SunOS box
> >> available?
> >>
> >> Martin
> >>
> >> <sunos.tgz>
> >>
> >> On 9 Nov 2008, at 17:04, Jean-Michel Campin wrote:
> >>
> >>> Hi Jean & Martin,
> >>>
> >>> The new version of genmake2 works well on most platforms (forward &
> >>> adjoint
> >>> tests), but likely that we have a problem on "rays" & "solarv" (both
> >>> SunOS)
> >>> since not a single test did compile.
> >>> Martin, could you send us a Makefile (+ make.log ? /
> >>> genmake_warnings ?)
> >>> from each of them ?
> >>> Thanks,
> >>> Jean-Michel
> >>>
> >>> On Fri, Nov 07, 2008 at 06:53:00AM -0600, Jean Utke wrote:
> >>>> Hi,
> >>>>
> >>>>
> >>>> I looked at today's summary and see that now on faulks all but one
> >>>> of the
> >>>> adjoint tests passed.
> >>>> But then there are failures on aces/eddy etc.  It seem like these
> >>>> ran before you put
> >>>> the "fixed" version in, correct?
> >>>>
> >>>> Jean
> >>>>
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> MITgcm-devel mailing list
> >>> MITgcm-devel at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >   
> 
> 
> -- 
> Jean Utke
> Argonne National Lab. / MCS
> 9700 S Cass Ave., Argonne, IL, 60439, USA
> phone 630 252 4552 / mobile 630 363 5753
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel