Chris - please take a quick look - Re: [MITgcm-devel] Re: [Fwd: Re: latest genmake2 variant]

chris hill cnh at mit.edu
Wed Nov 12 12:01:20 EST 2008 

Jean,

  Can we comment out the line as it was before and see if that works 
everywhere or does that cause a _practical_ problem for you (i.e. it 
doesn't matter if its a philosophical problem for you as long as it 
works :-) ).

Chris
Jean Utke wrote:
> Hi Jean-Michel.
> 
> I didn't see any more replies to this.
> May be somebody else (Chris ? ) could comment on the
> intention in genmake wrt the  preprocessing (see  A and B below)
> If we comment out the line again then we reenable a built-in rule ( at
> least gnu make has one)
> and it still is not clear to me that this is what should happen.
> Martin said when he comments out the line in question it works  on  the 
> solaris box.
> To me that means that at least part of the build must rely on a built-in
> rule
> and one wants to bypass the explicit preprocessing step.
> But then I don't quite understand why it cannot find the F->f->o rule chain
> even if the direct rule isn't there.Does it not set the $FS correctly?
> 
> In short if I were to comment the line out again I still wouldn't be sure
> what I am doing.  Is there are solaris machine that I can try this on?
> 
> Jean
> 
> 
> 
> 
> 
> Jean-Michel Campin wrote:
>> 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
>>>     
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>   
> 
>

More information about the MITgcm-devel mailing list