Re: mkoctfile urgently needs attention before Octave 3.6.0 release

[Lukas Reichlin]

On 29.12.2011, at 22:36, Ben Abbott wrote:

> 
> 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

Yes, that makes more sense to me. There are better naming schemes than my 
proposed one for sure. I don't care that much about the naming scheme as long 
as it provides the functionality I want.

Lukas