RE: build_packages.m script, visibility?

[Oliver Heimlich]

Am 29. Dezember 2015 15:00:47 MEZ, schrieb JohnD <address@hidden>:
>
>
>> -----Original Message-----
>> From: Oliver Heimlich [mailto:address@hidden
>> Sent: Tuesday, December 29, 2015 7:20 AM
>> To: John Donoghue
>> Cc: Octave Maintainers List; John W. Eaton; octave-maintainers;
>PhilipNienhuis
>> Subject: Re: build_packages.m script, visibility?
>> 
>> On 27.12.2015 22:06, John Donoghue wrote:
>> > Pushed http://hg.octave.org/mxe-octave/rev/bdcddfdc57d0
>> >
>> > There is a python script tools/pkg-install.py that is called from
>make
>> > to build/install the package - a lot of the code is a a close
>> > translation of octave to python (I'm not a particularly good python
>> > programmer so sorry to those that are)
>> 
>> Is the python script called by the installer or during creation of
>the installer?  I
>> find it complicated to duplicate what is already done by pkg in
>Octave (see
>> below).
>> 
>
>It is called during the creation of the installer - see Makefile.in
>OCTAVE_FORGE_PKG_BUILD
>
>> > The post_install.m file from within a package (if one exists) is
>> > copied to share/octave/site/m/once_only/  I had thought of adding a
>> > script that on first run would go through and run anything in that
>> > directory one time and then remove it?
>> 
>> post_install.m is used by two packages only.  “io” moves a PKG_ADD
>file around
>> and “stk” removes corr, graphics_toolkit, isrow, linsolve, and
>quantile from
>> stk/inst/misc/mole.  Could this be patched away in mxe-octave?  If
>not, you
>> have to make sure that the scripts are called with the right
>parameters
>> (installation paths and information from DESCRIPTION).
>> 
>I guess could be patched - thoughts  anyone?
>We have to read DESCRIPTION from our script anyway, so probally isn’t
>much of a problem
>
>> 
>> 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.
>
>Anyway - what I got to is now up there so feel free to change it. The
>amount I time I can spend on it a while may be sporadic.

I have tested the current mxe-octave with binary packages (the python script 
moves all package files into the right place, so they get installed together 
with Octave, the installer does a pkg rebuild at the end). It worked quite well 
and did not require additional time after installation.