Re: mkoctfile urgently needs attention before Octave 3.6.0 release

[Ben Abbott]

On Dec 29, 2011, at 3:29 PM, Lukas Reichlin wrote:

> On 29.12.2011, at 20:50, Jordi Gutiérrez Hermoso wrote:
> 
>> 2011/12/29 Lukas Reichlin <address@hidden>:
>>> 
>>> On 29.12.2011, at 17:52, Jordi Gutiérrez Hermoso wrote:
>>> 
>>>> 2011/12/29 Lukas Reichlin <address@hidden>:
>>>>> On 29.12.2011, at 14:47, Jordi Gutiérrez Hermoso wrote:
>>>>>> 2011/12/29 Lukas Reichlin <address@hidden>:
>>>>>>> In order to circumvent these problems, I propose the following
>>>>>>> solution that works from both Octave prompt and OS shell: Addition
>>>>>>> of a new option "--link-all-libs" to mkoctfile
>>>>>> 
>>>>>> No, this is not the solution. We need to understand the actual
>>>>>> problem. You are proposing a heavy-handed solution because you don't
>>>>>> understand the actual problem, and neither do we. We should work to do
>>>>>> that instead of trying to revert to an old barbaric method of linking
>>>>>> that happened to work for your case.
>>>>>> 
>>>>>> Marco has already proposed a solution that seems to work for other
>>>>>> cases. We are only missing yours.
>>>>> 
>>>>> I'm glad that Marco sent me a patch. But it's just a workaround for
>>>>> the problem, not a solution. It's not good when you have to resort
>>>>> to the shell, query some configuration variables and then feeding
>>>>> the result to the next call of mkoctfile.
>>>> 
>>>> This *is* a good solution. It's not something we invented for Octave.
>>>> For example, pkg-config also does the same thing for many other Unix
>>>> packages. It's also convenient. You could for example do
>>>> 
>>>>   mkoctfile foo.cc $(mkocfile -p BLAS_LIBS)
>>>> 
>>>> This is just how shells work.
>>>> 
>>>>> It should be possible from the Octave prompt and without tedious
>>>>> fiddling with intermediate variables.
>>>> 
>>>> I don't see a huge priority to recreate a Unix shell in Octave, so if
>>>> calling mkoctfile.m involves using an intermediate variable, I don't
>>>> see a problem. You don't even need the intermediate variable. For
>>>> example, you could do
>>>> 
>>>>   mkoctfile("foo.cc", mkoctfile("-p","BLAS_LIBS"))
>>>> 
>>>> which is roughly equivalent to its corresponding Unix shell call
>>>> above.
>>>> 
>>>> The only bug remaining is figuring out what linking flags you need on
>>>> McIntosh OS 10, and why mkoctfile -p LAPACK_LIBS isn't producing those
>>>> flags.
>>> 
>>> I meant that it should work with only one call to mkoctfile. Something like
>>> 
>>>   mkoctfile foo.cc --link-to-blas --link-to-lapack
>> 
>> Why does this make a difference? Would you prefer if instead the
>> variables were printed by octave-config instead of mkoctfile? What's
>> the problem with calling mkoctfile twice?
>> 
>> - Jordi G. H.
> 
> This way (mkoctfile foo.cc --link-to-blas --link-to-lapack) mkoctfile can 
> deal with conflicts. We just tell mkoctfile to link to some of its libraries 
> without giving the platform-specific names like -framework Accelerate stored 
> in a variable. No printing is necessary this way. If you use two calls to 
> mkoctfile, it's the user who has to handle the conflicts on every platform. 
> This is unecessary complexity and should be hidden from the user.
> 
> If you think it's too much work to add individual options like 
> "--link-to-blas", "--link-to-fftw" and so on you can still add 
> "--link-all-libs" that restores the old barbaric method of linking. Why are 
> you so strictly against it? It worked quite well until now and nobody would 
> be forced to use that barbaric option.
> 
> The last thing I want to do is adding platform-specific tweaks to my package 
> makefiles. That kind of stuff belongs to mkoctfile internals.
> 
> Lukas

Options like "--link-to-blas" look too specific to me. Would 
--link-to-BLAS_LIBS, --link-to-LAPACK_LIBS, --link-to-FFTW_LIBS make more sense 
?

In this form, what is needed can be obtained directly form octave_config_info().

Ben