octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: build_packages.m script, visibility?


From: JohnD
Subject: RE: build_packages.m script, visibility?
Date: Tue, 29 Dec 2015 09:00:47 -0500


> -----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.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]