Re: mkoctfile urgently needs attention before Octave 3.6.0 release

[Lukas Reichlin]

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