Re: build_packages.m script, visibility?

[Oliver Heimlich]

On 29.12.2015 17:02, John W. Eaton wrote:
> 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
> 

I have done:

1) pkg ("build", …) on a package source tarball using Octave 3.8.2 from
Debian Jessie. This created a binary tarball that contained a folder
[pkg]/inst/x86_64-pc-linux-gnu-api-v49+/ with oct-files and doc-cache.
2) Renamed that folder (inside the binary tarball) into
i686-w64-mingw32-api-v50+
3) Replace the oct-files with the cross-compiled oct-files from Octave
4.0.1-rc1 (inside the binary tarball)
4) Installed the package in Octave 4.0.1-rc1 on Windows.

The package works. However, package installation still goes through
generation of PKG_ADD and doc-cache (at least for the arch independent
files).  Recreation of doc-cache would not be required, it is already
contained in the binary package tarball.  I am not sure about PKG_ADD.

So, we already have most of what is needed.  The only things left to do are:
 - Add octave as a build dependency for mxe-octave (version 3.8 should
suffice, maybe you can use even older versions)
 - Use pkg ("build", …) to generate a binary package tarball (replace
mkoctfile with something that cross-compiles and make sure that the
paths in the tarball are correct)
 - Short-circuit doc_cache_create and create_pkgadddel if
doc-cache/PKG_ADD file is present

Then, we have a binary package tarball, which can be installed in a
second on the x86_64-w64-mingw32 system using pkg ("install", …).

Oliver

signature.asc
Description: OpenPGP digital signature