essage: 5
Date: Tue, 29 Dec 2015 11:02:09 -0500
From: "John W. Eaton" <address@hidden>
To: JohnD <address@hidden>, 'Oliver Heimlich'
<address@hidden>
Cc: 'PhilipNienhuis' <address@hidden>, 'octave-maintainers'
<address@hidden>, 'Octave Maintainers List'
<address@hidden>
Subject: Re: build_packages.m script, visibility?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed
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