[MITgcm-devel] genmake2 problem

[Patrick Heimbach]

Hi Jean-Michel,

Quoting Jean-Michel Campin <jmc at ocean.mit.edu>:

> Hi Patrick,
>
> I propose to try to stop the genmake2 process
> only if #define ALLOW_{PKG} is found in CPP_OPTIONS.h
> (instead of #define ALLOW_{PKG}* as it is now).
> Will it solve your problem ?

I had indeed assumed it would work this way (i.e. stop for
#define ALLOW_{PKG} as opposed to #define ALLOW_{PKG}* ),
so I was surprised that the latter was the case.
The former would be a nice solution, but it's not crucial
and as Ed mentioned, one easy workaround for now is to
comment out the "return" as a quick fix
(another fix was to rename pkg/bulkf to e.g. pkg/bulk_forcing
which is how it's now and doesn't interfere with ALLOW_BULKFORMULA).

Again, don't worry about it for now.

Cheers
-p.



> Jean-Michel
>
> On Thu, Apr 06, 2006 at 01:12:03PM -0400, Ed Hill wrote:
>> On Thu, 2006-04-06 at 10:58 -0400, Patrick Heimbach wrote:
>> >
>> > there's a sublte problem with genmake2.
>> > We now ommit #define of packages in CPP_OPTIONS.h
>> > which is good.
>> > However, a funny thing happens when you have
>> > a CPP flag that's very similar to a package name,
>> > but is not a package name.
>> > For example,  if you add the flag
>> > #define ALLOW_SEAICEFFF
>> > in lab_sea/code/CPP_OPTIONS.h
>> > genmake2 will choke
>> >
>> > Error: In ../code/CPP_OPTIONS.h there is an illegal line: #define
>> > ALLOW_SEAICEFFF
>>
>>
>> Hi Patrick,
>>
>> I can think of at least three ways to fix that and here they are (in my
>> opinion) ordered from best to worst:
>>
>>  1) we all agree to use flags of the form ALLOW_${PKG_NAME}
>>     only for packages -- or perhaps some other pattern such
>>     as ENABLE_${PKG_NAME}
>>
>>  2) within genmake2, turn off the bit of code that tries to
>>     dis-allow the manual setting of packages with #define
>>     statements
>>
>>  3) I write a bit of code that is smart enough to enumerate
>>     all the package names so that non-package ALLOW_* flags
>>     won't get flagged as being an error -- and keep the
>>     now-smarter error checking code [but I think this is a
>>     really silly and fragile way to do things]
>>
>> So, which approach do you and others want to use?
>>
>> Ed
>>
>> --
>> 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://mitgcm.org/mailman/listinfo/mitgcm-devel
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>



--------------------------------------------------------
Patrick Heimbach   Massachusetts Institute of Technology
FON: +1/617/253-5259                  EAPS, Room 54-1518
FAX: +1/617/253-4464             77 Massachusetts Avenue
mailto:heimbach at mit.edu               Cambridge MA 02139
http://www.mit.edu/~heimbach/                        USA