Re: More arch dependent shuffling needing

[David Bateman]

Orion Poplawski wrote:
> Getting close, finally build the octave-forge rpm.  The following files
> ended up in /usr/share and need to be in /usr/libexec:
> 
> octave-forge.i386: E: arch-dependent-file-in-usr-share
> /usr/share/octave/packages/secs2d-0.0.3/Utilities/Ucompconst.oct
> octave-forge.i386: E: arch-dependent-file-in-usr-share
> /usr/share/octave/packages/secs2d-0.0.3/Utilities/Ucomplap.oct
> octave-forge.i386: E: arch-dependent-file-in-usr-share
> /usr/share/octave/packages/secs2d-0.0.3/Utilities/Ubern.oct
> octave-forge.i386: E: arch-dependent-file-in-usr-share
> /usr/share/octave/packages/engine-1.0.3/liboct.a
> octave-forge.i386: E: arch-dependent-file-in-usr-share
> /usr/share/octave/packages/audio-1.0.2/bin/aurecord
> octave-forge.i386: E: arch-dependent-file-in-usr-share
> /usr/share/octave/packages/secs1d-0.0.3/Utilities/Ubern.oct
> octave-forge.i386: E: arch-dependent-file-in-usr-share
> /usr/share/octave/packages/secs2d-0.0.3/Utilities/Uscharfettergummel.oct
> 
> 
> So, looks like we (pkg.m) need to handle .oct files in sub-directories,
> binary executables and libraries.

The sub-directories aren't treated by pkg.m and secs[12]d just copied
them to inst, which is why ou see what you see. Easier to just make
secs[12]d more like the other packages and keep the oct-files is src/
directly rather than a sub-directory of secs[12]d

> In the specific case of aurecord, is this the same as the one provided
> by ttp://nas.codebrilliance.com?  In this case, I probably won't ship
> it.  

I can't answer that. Paul Kienzle will have to.

> However, in the general case, does octave add any of the package
> paths to the system search path?  The audio .m files simply run
> "aurecord" without any path.

Octave maintains its own EXEC_PATH and can modify it with the EXEC_PATH
function. So the pkg command adds the bin directories it finds for the
packages to the EXEC_PATH.

The problem I see is that the code in bin/ doesn't have to be
architecture dependent. It might easily be in a scripting language like
shell, perl, etc. An example of this is the extras/pdb package with it
ramsol.sh script.

So to meet your requirements we need to have pkg be able to distinguish
between architecture dependent and independent files in the bin/
directory and copy them to the appropriate place. I see no simple way to
do this. I can't assume that only 7-bit ascii file are architecture
independent, Soren has an 8-bit character in his name and in all the
code he writes :-)  ... I can't assume that the "file" command is
available.

The only viable solution I see to this is to modify the package format
slightly and add a special bin/FILES file to distinguish architecture
dependent and independent files. The easily is assume all files listed
in FILES are architecture independent and others are architecture
dependent. Its easier that way as for architecture dependent only files
in bin/, the bin directory does even need to exist at the outset (see
the audio package).

Orion if this is a viable solution to you, I'll make the necessary
modifications.

> With engine, how is this supposed to be used?  Files really should be in
> /usr/include and /usr/lib (or /usr/lib64) for development.  I guess
> someone could point elsewhere.  In any case, the .a needs to be in an
> arch specific directory.

The engine package is a rather special case. Its not supposed to be used
from within Octave at all, but rather with external applications as a
means to access the functionality of Octave externally. So in a certain
sense it shouldn't be an octave-forge package in the same manner as the
others.

I see two easy means of treating this. At the moment the src/FILES file
is parsed and only files ending in .oct or .mex are considered to be
architecture dependent. We could assume that all files in FILES are
architecture dependent and then liboct.a and engine.h will go into libexec/.

The other alternative would be to deliberately throw and error in the
src/Makefile for the "all" target once everything is built and liboct.a
and engine.h are copied somewhere temporary (even they aren't moved pkg
will clean-up the build directory removing it after the error). In this
manner the user can be informed of the location of the two files and not
install engine as a package. This rather prevents the inclusion of
engine in Fedora.

Doing it properly and installing in /usr/include and /usr/lib means that
the SPEC file for engine should have its own special install target..
This is probably the better solution in the end and I'd tend to leave
the current functionality in place for the user who installs without
root privilege..


> Thanks everyone (esp. David Bateman) for your help with this.

I have an interest in seeing this getting into at least one distribution
rapidly. It is THE priority to me before an Octave 3.0 release..

D.