glpk patch for octave

[M. White]

On Feb 28, 2007, at 7:32 AM, macports-users- 
request at lists.macosforge.org wrote:

> From: David MacMahon <davidm at astro.berkeley.edu>
> Subject: Re: glpk patch for octave
> To: macports-users at lists.macosforge.org
> Message-ID: <00209460-3FC5-4F61-A488-314E4183D90A at astro.berkeley.edu>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> On Feb 27, 2007, at 20:49 , M. White wrote:
>> Just a question here, I've noticed that the recommended fix for
>> GLPK includes:
>>
>>   #ifdef GLPK_PRE_4_15
>>
>> which seems to indicate to me that it will still be a problem if
>> someone happens to
>> be running 4.14 (as the bindings changed from 4.13 to 4.14 and
>> apparently the
>> EXTRA.mem changed from 4.14 to 4.15.  So technically, it looks like
>> octave with the
>> revisions will work with any version of glpk  _except_ 4.14.  Is
>> this correct?  (If you
>> read closely, the change had only been tested with 4.11 and 4.15.)
>
> I believe the glpk patch for the octave port modifies __glpk__.cc
> directly to declare and call functions that still exist in the
> library but are no longer declared (i.e. exposed) in the gplk header
> file.  It does not setup or use the GLPK_PRE_4_15 macro.
>
> I'm not sure whether this results in a .cc file that is compatible
> with version 4.14, but since the current glpk port is revision 4.15
> does anyone need 4.14 compatibility?
>
> Dave
>

Ah, if that is the case, then the patch should work for 4.14 (but not
for earlier than 4.14).  The only functionality that would be lost is
the EXTRA.mem call (which if __glpk__.cc was patched the way
I expect it was, it will now have a line something like *mem =  0;)
and that is not too much of a problem, as in 4.15 that functionality
is lost anyway.  I was not sure if you were trying to patch keeping
in mind backwards compatibility or not.

  - M.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20070228/701f2010/attachment.html