Chris - please take a quick look - Re: [MITgcm-devel] Re: [Fwd: Re: latest genmake2 variant]
Jean Utke
utke at mcs.anl.gov
Tue Nov 11 10:42:20 EST 2008
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
>
--
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