Re: build_packages.m script, visibility?

[John W. Eaton]

On 12/29/2015 09:00 AM, JohnD wrote:
> > -----Original Message-----
> > From: Oliver Heimlich [mailto:address@hidden

> > Most of above problems arise because we cannot execute the cross-compiled
> > Octave binary and utilize it to produce a tarball that could be used by the
> > installer during installation.
> >
> > How about using a native Octave to assist the process?
> >   - use pkg ("build", …) to produce a binary version of the package
> >   - add cross-compiled oct-files into the tarball (under
> > “inst/i686-w64-mingw32-api-v50+/”) or inject a cross-compiling mkoctfile
> > during the previous step
> >   - let the installer move the files to the right places, that is:
> >     a) /inst/[arch] --> lib/octave/packages/[pkg]-[version]/
> >     b) /inst/*      --> share/octave/packages/[pkg]-[version]/
> >     c) /*           --> share/octave/packages/[pkg]-[version]/packinfo/
> >     d) Run octave-cli at the end of installation with "pkg rebuild" (the 
> > process will
> > have the same privileges as the installer and can create the
> > share/octave/octave_packages file).
> >     e) Run octave-cli at the end of installation to process the post_install.m 
> > scripts.
> >
> > Oliver
>
> At that point you are depending on a native built octave to be there, probally 
> of the same version.  I  am not sure that even using that method will be any 
> 'easier' than how it now is.

It would be nice to not have to duplicate (all of) the logic of building 
packages in pkg.m and an mxe-octave script.

It is possible that we would need the same version of Octave that could 
be run on the build system, but with some care maybe we can minimize 
that problem?

Currently pkg.m only knows how to handle source distributions in the 
form of a tar.gz file, correct?  Could we modify it to handle a "binary" 
package that includes the .oct files (could be cross compiled) and then 
simply complete the installation steps as part of the installation 
process on the target system without having to compile .oct files (since 
that step would already be done)?

So instead of distributing, say, signal-1.3.2.tar.gz, we would 
distribute something like signal-1.3.2_x86_64-w64-mingw32.tar.gz that 
includes the compiled .oct files and pkg.m would know how to install 
that without rebuilding the .oct files.  This step of running pkg.m 
would be done on the x86_64-w64-mingw32 system.

These binary packages could also include pre-built documentation files.

Just compiling .oct files and generating documentation shouldn't require 
duplication of too much of pkg.m.  If we need a native version of Octave 
to build the documentation files, then maybe we could keep the scripts 
that do that job compatible with older versions of Octave so that it 
isn't necessary to require the exact same versions for the native and 
cross-built Octave.

I expect that installing the binary packages would be significantly 
faster than installing from source.

jwe