Re: [Pkg-octave-devel] Multi-archifying Octave

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-octave-devel] Multi-archifying Octave

Jordi Gutiérrez Hermoso-2
CC'ing the Octave dev list, brief context: future Debian is going
multiarch and is wondering what to do about the arch-specific names in
Octave's oct-file paths.

On 28 February 2012 15:31, Thomas Weber <[hidden email]> wrote:

> On Mon, Feb 27, 2012 at 08:14:41PM -0500, Jordi Gutiérrez Hermoso wrote:
>> On 27 February 2012 18:08, Thomas Weber <[hidden email]> wrote:
>> > On Fri, Feb 24, 2012 at 09:37:26PM +0100, Sébastien Villemot wrote:
>> >>  /usr/lib/x86_64-linux-gnu/octave/3.6.1/oct/x86_64-pc-linux-gnu/svd.oct
>> >>  /usr/lib/x86_64-linux-gnu/octave/packages/3.6.1/optim-1.0.17/x86_64-pc-linux-gnu-api-v48+/
>> >>
>> >> Note that there are two triplets in the paths.
>> >>
>> >> Functionally this is not a problem, but it is a little ugly, since there
>> >> is some sort of duplication.
>> >
>> > I'm not sure about the "no problem part".
>> > On i386, the paths will loke like
>> > /usr/lib/i386-linux-gnu/.../i486-pc-linux-gnu
>> > so the numbers are different.
>> >
>> > So, will this work with multi-arch?
>>
>> Should we give Octave a configure-time option to not use arches in
>> directory names? We could do that for future releases.
>
> Maybe instead of an option, just remove the arch parts.
> I don't know what purpose they solve other than adding one more
> directory to Octave's path. It's not like an ARM Octave binary can load
> .oct files from an i386 build.

I believe it's an effort to emulate the .mex64, .mexglx, and .mexglx64
filename extensions of Matlab, the point being that you can have
several oct files in a network drive or something and have several
terminals mount that network drive and using oct files without all
needing to be the same architecture.

So the same reason that Debian is going multiarch, I suppose. But if
Debian is already doing the multi-arching, I don't see a reason why
Octave should do it too, so it makes sense to disable the
multi-arching if the OS is already going to do it.

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-octave-devel] Multi-archifying Octave

bpabbott
Administrator
On Feb 28, 2012, at 4:13 PM, Jordi Gutiérrez Hermoso wrote:

> CC'ing the Octave dev list, brief context: future Debian is going
> multiarch and is wondering what to do about the arch-specific names in
> Octave's oct-file paths.
>
> On 28 February 2012 15:31, Thomas Weber <[hidden email]> wrote:
>> On Mon, Feb 27, 2012 at 08:14:41PM -0500, Jordi Gutiérrez Hermoso wrote:
>>> On 27 February 2012 18:08, Thomas Weber <[hidden email]> wrote:
>>>> On Fri, Feb 24, 2012 at 09:37:26PM +0100, Sébastien Villemot wrote:
>>>>>  /usr/lib/x86_64-linux-gnu/octave/3.6.1/oct/x86_64-pc-linux-gnu/svd.oct
>>>>>  /usr/lib/x86_64-linux-gnu/octave/packages/3.6.1/optim-1.0.17/x86_64-pc-linux-gnu-api-v48+/
>>>>>
>>>>> Note that there are two triplets in the paths.
>>>>>
>>>>> Functionally this is not a problem, but it is a little ugly, since there
>>>>> is some sort of duplication.
>>>>
>>>> I'm not sure about the "no problem part".
>>>> On i386, the paths will loke like
>>>> /usr/lib/i386-linux-gnu/.../i486-pc-linux-gnu
>>>> so the numbers are different.
>>>>
>>>> So, will this work with multi-arch?
>>>
>>> Should we give Octave a configure-time option to not use arches in
>>> directory names? We could do that for future releases.
>>
>> Maybe instead of an option, just remove the arch parts.
>> I don't know what purpose they solve other than adding one more
>> directory to Octave's path. It's not like an ARM Octave binary can load
>> .oct files from an i386 build.
>
> I believe it's an effort to emulate the .mex64, .mexglx, and .mexglx64
> filename extensions of Matlab, the point being that you can have
> several oct files in a network drive or something and have several
> terminals mount that network drive and using oct files without all
> needing to be the same architecture.
>
> So the same reason that Debian is going multiarch, I suppose. But if
> Debian is already doing the multi-arching, I don't see a reason why
> Octave should do it too, so it makes sense to disable the
> multi-arching if the OS is already going to do it.
>
> - Jordi G. H.


Jordi,

I'm unfamiliar with what is being proposed for Debian.

MacOS already has a "universal" option to allow libraries and binaries to be built which support more than one architecture. Is Debian planning something similar, or do they plan to build different libs and place them in different paths ?

Ben




Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-octave-devel] Multi-archifying Octave

Jordi Gutiérrez Hermoso-2
2012/2/28 Ben Abbott <[hidden email]>:

> MacOS already has a "universal" option to allow libraries and
> binaries to be built which support more than one architecture. Is
> Debian planning something similar, or do they plan to build
> different libs and place them in different paths ?

The latter. The problem is that Octave already does this, so it
produces some ugly paths where the arch is recorded twice. The Debian
packagers aren't sure why is Octave doing this, so we are looking for
a pretty solution.

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-octave-devel] Multi-archifying Octave

John W. Eaton
Administrator
In reply to this post by Jordi Gutiérrez Hermoso-2
On 28-Feb-2012, Jordi Gutiérrez Hermoso wrote:

| the point being that you can have
| several oct files in a network drive or something and have several
| terminals mount that network drive and using oct files without all
| needing to be the same architecture.

Yes, back in the olden times when disk space was expensive this sort
of arrangement was common with heterogeneous networks of Unix
workstations.  So the idea was to allow a single installation of
Octave to work on multiple architectures while sharing all the
architecture independent files.

What is the motivation for doing this now in Debian?

Can you achieve what you need without having a special option?  Is it
sufficient to explicitly set the values for the following variables?

  OCTAVE_SET_DEFAULT(archlibdir,
    '$(libexecdir)/octave/$(version)/exec/$(canonical_host_type)')
  OCTAVE_SET_DEFAULT(localarchlibdir,
    '$(libexecdir)/octave/site/exec/$(canonical_host_type)')
  OCTAVE_SET_DEFAULT(localapiarchlibdir,
    '$(libexecdir)/octave/$(api_version)/site/exec/$(canonical_host_type)')
  OCTAVE_SET_DEFAULT(localverarchlibdir,
    '$(libexecdir)/octave/$(version)/site/exec/$(canonical_host_type)')
  OCTAVE_SET_DEFAULT(octfiledir,
    '$(libdir)/octave/$(version)/oct/$(canonical_host_type)')
  OCTAVE_SET_DEFAULT(localoctfiledir,
    '$(libdir)/octave/site/oct/$(canonical_host_type)')
  OCTAVE_SET_DEFAULT(localapioctfiledir,
    '$(libdir)/octave/site/oct/$(api_version)/$(canonical_host_type)')
  OCTAVE_SET_DEFAULT(localveroctfiledir,
    '$(libdir)/octave/$(version)/site/oct/$(canonical_host_type)')

It seems to me that something like

  configure \
    archlibdir='$(libexecdir)/octave/$(version)/exec' \
    localarchlibdir='$(libexecdir)/octave/site/exec' \
    ...

should work.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-octave-devel] Multi-archifying Octave

Sébastien Villemot
"John W. Eaton" <[hidden email]> writes:

> On 28-Feb-2012, Jordi Gutiérrez Hermoso wrote:
>
> | the point being that you can have
> | several oct files in a network drive or something and have several
> | terminals mount that network drive and using oct files without all
> | needing to be the same architecture.
>
> Yes, back in the olden times when disk space was expensive this sort
> of arrangement was common with heterogeneous networks of Unix
> workstations.  So the idea was to allow a single installation of
> Octave to work on multiple architectures while sharing all the
> architecture independent files.
>
> What is the motivation for doing this now in Debian?
>
> Can you achieve what you need without having a special option?  Is it
> sufficient to explicitly set the values for the following variables?
>
>   OCTAVE_SET_DEFAULT(archlibdir,
>     '$(libexecdir)/octave/$(version)/exec/$(canonical_host_type)')
>   OCTAVE_SET_DEFAULT(localarchlibdir,
>     '$(libexecdir)/octave/site/exec/$(canonical_host_type)')
>   OCTAVE_SET_DEFAULT(localapiarchlibdir,
>     '$(libexecdir)/octave/$(api_version)/site/exec/$(canonical_host_type)')
>   OCTAVE_SET_DEFAULT(localverarchlibdir,
>     '$(libexecdir)/octave/$(version)/site/exec/$(canonical_host_type)')
>   OCTAVE_SET_DEFAULT(octfiledir,
>     '$(libdir)/octave/$(version)/oct/$(canonical_host_type)')
>   OCTAVE_SET_DEFAULT(localoctfiledir,
>     '$(libdir)/octave/site/oct/$(canonical_host_type)')
>   OCTAVE_SET_DEFAULT(localapioctfiledir,
>     '$(libdir)/octave/site/oct/$(api_version)/$(canonical_host_type)')
>   OCTAVE_SET_DEFAULT(localveroctfiledir,
>     '$(libdir)/octave/$(version)/site/oct/$(canonical_host_type)')
>
> It seems to me that something like
>
>   configure \
>     archlibdir='$(libexecdir)/octave/$(version)/exec' \
>     localarchlibdir='$(libexecdir)/octave/site/exec' \
>     ...
>
> should work.
This should indeed be enough for Octave core.

But, as already noted by Thomas Weber, this does not address the issue
for add-on packages, because pkg.m hardcodes the arch-specific paths
(see the getarch() function there).

--
Sébastien Villemot
Researcher in Economics & Debian Maintainer
http://www.dynare.org/sebastien
Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-octave-devel] Multi-archifying Octave

John W. Eaton
Administrator
On 29-Feb-2012, Sébastien Villemot wrote:

| This should indeed be enough for Octave core.
|
| But, as already noted by Thomas Weber, this does not address the issue
| for add-on packages, because pkg.m hardcodes the arch-specific paths
| (see the getarch() function there).

I'm not sure what is best for that.  Do you have any suggestions?
What change are you using for Debian?

I'd like to remind you that if you find the need to patch Octave for
Debian, it is probably best to at least discuss the changes with us.
We might have other ideas that could help you or we could incorporate
your changes so that you don't have to maintain separate patches.
Ideally, I'd like to see distributions building Octave without the
need for special patches.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: [Pkg-octave-devel] Multi-archifying Octave

Sébastien Villemot
"John W. Eaton" <[hidden email]> writes:

> On 29-Feb-2012, Sébastien Villemot wrote:
>
> | This should indeed be enough for Octave core.
> |
> | But, as already noted by Thomas Weber, this does not address the issue
> | for add-on packages, because pkg.m hardcodes the arch-specific paths
> | (see the getarch() function there).
>
> I'm not sure what is best for that.  Do you have any suggestions?
> What change are you using for Debian?
The only change that we made is that at configure time we give
--libdir=/usr/lib/<triplet> (where <triplet> is x86_64-linux-gnu on my
system) instead of --libdir=/usr/lib previously. No more. Debian is
progressively making this change in all its packages, since multi-arch
is a release goal for the next version of Debian [1].

The only annoyance in the case of Octave is that there are now two
triplets in the path of most arch-specific files, and in addition these
triplets are different (Debian use slightly different triplets than
GNU's). But we have decided to live with that for now. Functionally it
should not a problem, since changing --libdir is supported by
Octave. And removing the extra triplet would imply a substantial patch
to pkg.m, which I personally consider--as you do--as an undesirable
thing.

[1] http://wiki.debian.org/ReleaseGoals/MultiArch

--
Sébastien Villemot
Researcher in Economics & Debian Maintainer
http://www.dynare.org/sebastien
Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594

attachment0 (851 bytes) Download Attachment