octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GLPK API change


From: John W. Eaton
Subject: Re: GLPK API change
Date: Thu, 8 Feb 2007 15:39:41 -0500

On  8-Feb-2007, Michael Goffioul wrote:

| John W. Eaton a écrit :
| > OK, but what is the right feature test for autoconf in this case?  We
| > should not be encoding version numbers there if at all possible.
| >   
| 
| The test should check for _glp_lpx_simplex symbol (note the leading 
| underscore).
| But maybe the safest solution is to write a custom test that uses 
| lpx_simplex instead.
| Indeed, the user API hasn't changed, but this API is #define'd in GLPK 
| headers, and
| the symbol to which it's #define'd has changed. For instance:
| 
| #define lpx_simplex glp_lpx_simplex
| 
| became
| 
| #define lpx_simplex _glp_lpx_simplex
| 
| So, if you write a custom test that tries to link a piece of code using 
| lpx_simplex,
| this should be portable. OTOH, you must check for the header first, because
| you'll need to include it in your custom test.

My question was more about what kind of feature test should be used
for other API changes, like the data types used for variables.

In any case, I fixed the configure script to check for
_glp_lpx_simplex if glp_lpx_simplex is not found and I also included
the #ifndef/#define lines in your previous message.

That just leaves the cast you proposed.  Why is that needed?
Precisely what problem does it solve?

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]