Chris - please take a quick look - Re: [MITgcm-devel] Re: [Fwd: Re: latest genmake2 variant]
Jean Utke
utke at mcs.anl.gov
Thu Nov 13 13:55:55 EST 2008
Hi Chris,
Right now I don't see a *practical* problem with commenting it out.
I will go in the corner with my philosophical problem and grumble
where nobody hears me. :-)
Jean
chris hill wrote:
> 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
>>>
>>
>>
>
> _______________________________________________
> 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
More information about the MITgcm-devel
mailing list