Re: build_packages.m script, visibility?

[Oliver Heimlich]

On 27.12.2015 01:04, John W. Eaton wrote:
> On 12/26/2015 08:09 AM, John Donoghue wrote:
>> On 12/25/2015 06:18 PM, Oliver Heimlich wrote:
>>> On 26.12.2015 00:11, Nicholas Jankowski wrote:
>>>> I always install via the zip file version and don't run into any admin
>>>> issues with packages. Can anyone comment if this is always the case, or
>>>> only for certain packages? Same problem with the pkg install or pkg
>>>> update commands?
>>> This is because you installed Octave in C:\Octave\… and I did install it
>>> (with higher privileges) in %ProgramFiles%.  Later, when running it
>>> again, I do not have permission to unzip / install packages in
>>> %ProgramFiles%
>>>
>>>> Having it install the default when the program is installed would
>>>> (should) be easier as it should occur with the same access level
>>>> used to
>>>> run the Octave installer.
>>> Yes, this would eliminate a lot of pitfalls.
>>>
>>>> Would this happen by opening an instance of Octave set to run the build
>>>> packages script and exit? Can they be "built" before building the
>>>> installer so they're already installed?
>>> As far as I understand, the packages are cross-compiled, but
>>> build_packages.m does not consider this possibility and does a “classic”
>>> installation. It would suffice to extract the tarballs, put the files
>>> into the right directories and update the global package database. This
>>> should be possible to do with the installer and not run an Octave script
>>> during installation.
>>>
>>
>> build_packages.m does do the classic install command, however should not
>> be recompiling the packages if they were built already compiled.
>> In fact the makefile etc in the source directory is removed as part of
>> the mxe-octave cross build of the packages.

True, I have looked more into details. All packages but ltfat use
precompiled oct-files. Installation takes approximately 300 seconds for
ltfat and between 1 and 25 seconds for other packages. ltfat does not
contain precompiled oct-files, that's why this package takes so much
time and why I have originally thought, that there was no cross-compiled
package. However, it is only ltfat that does not use cross-compiled
oct-files and goes through a full recompilation during build_packages.m.

>> I have a script that is very close to ready for installing cross built
>> packages when building the mxe installer, but it fails on a couple of
>> the current packages and needs to be fixed to work for them.
>>
>> I can provide the script if someone has more time than I do at the
>> moment and wants to work on it?
> 
> Yes, please post it, or just add what you have now to the mxe-octave
> archive and we can go from there.  It would be great to cross-compile
> packages and have them distributed with binary distributions so that
> they are ready to install.  It would be even better if we could make
> that happen for the 4.0.1 release.
> 
> jwe

I was wondering why the runtime for the other packages was so unequal in
build_packages.m, and I used the profiler.  The generate_lookfor_cache
function takes up to 15 seconds per package and the create_pkgadddel
function takes up to 6.5 seconds per package.  The rest is mainly spent
for copying files.

Both generate_lookfor_cache and create_pkgadddel do not work for m-files
in @class or +package folders, so they are very fast for some packages
and slow for others—depending on the package's structure.

If we could completely skip “pkg install” and do this as part of the
installer, the package installation would much faster and much easier
for the user.  I will try to help with your script!

Oliver

signature.asc
Description: OpenPGP digital signature