SciPDL installer

[zmughal]

Automate the process of building a SciPDL installer for Mac OSX, Windows, and (maybe) Linux.

[mohawk2]

This is a Jan 2014 doc by Matthew Kenworthy on making SciPDL: https://www.mail-archive.com/[email protected]/msg05839/scipdl-2.007-maverick.pod

[mohawk2]

How to make MacOS installer packages: https://stackoverflow.com/questions/11487596/making-macos-installer-packages-which-are-developer-id-ready (linked from https://www.mail-archive.com/[email protected]/msg05884.html)

[mohawk2]

A better way entirely might be to make a brew recipe for PDL itself.

[zmughal]

A better way entirely might be to make a brew recipe for PDL itself.

Yeah, that's #21. Homebrew is created for building from source (or creating bottles) for a specific macOS version.

The SciPDL would be separate from that however as it is made for distribution to any macOS version. It would require building with a minimum target. I have an example script to do this using MacPorts for a Perl Gtk3 application https://github.com/orbital-transfer-example/perl-gtk3-starter-basic/blob/v0.0.1/maint/devops.yml#L40, https://github.com/orbital-transfer-example/perl-gtk3-starter-basic/blob/v0.0.1/maint/helper.pl#L763.

[mohawk2]

Great! I've read through the old SciPDL doc, and a big complication they had was from using the system Perl. Having just had to deal with the brew perl being upgraded, and having to remove the version-specific bits and then do lots of reinstallation in my local::lib dir, we'd want to avoid that here. Instead, we'd need to include our own Perl.

[karlglazebrook]

To answer a few questions:

SciPDL has only ever been MacOS.

My current version of SciPDL includes its own Perl. This has the advantage that it doesn't break if you update MacOS.

Matthew Kenworthy's instructions are now probably obsolete, since I took this back over a couple of years ago.

I no longer do 'MacOS packages', I understood these were deprecated or could only be done from Xcode? It does make it a bit nicer.

The current approach is to simply build the thing in /Applications/PDL and then copy those files in to a .dmg. One can then open the .dmg and do a drag to install, but then one has to run a script to bypass the Gatekeeper stuff. (Remove the quarantine flash from any files installed in this way). This is incredibly hacky and inelegant.

In terms of the 'automations' of the building, I do have a shell script that does the whole thing. It untars lots of packages, sometimes patches them, runs the configure/builds etc. There are about 7 of these, in addition to perl and PDL itself plus a dozen CPAN packages. I could certainly upload this to GitHub, or attach it here for you all to admire. However I would expect it to break if I started updating the various packages within it.

It is possible for the GitHub CI thing to build MacOS things?

[mohawk2]

@karlglazebrook Please, please let us see the shell scripts etc! :-) Copy-paste them into this issue if that is convenient for you, we can learn from them. It's very understood that updates might break things, this is the nature of the beast. And GitHub CI absolutely can build and package MacOS .dmg; this is an article on how to do it: https://medium.com/flutter-community/build-sign-and-deliver-flutter-macos-desktop-applications-on-github-actions-5d9b69b0469c

Since I've been dipping my toe in the water of Debian packaging, I am considering making a "scipdl" package for Debian, although they are a very slow-moving target - Oct 2021's new "bullseye" stable release has PDL 2.025, from Nov 2020.

Also we might make a CPAN package that simply depends on the various CPAN modules, maybe called PDL::SciBundle (or ::SciKarl, why not). The benefit of this is it could update quickly. Ideas extremely welcome, particularly on the name.

[karlglazebrook]

Sorry I just found a trove of old emails I had not seen!

Cut and paste FWIW

pgplot_hacks.zip

[karlglazebrook]

Oops it deleted the two shell scripts. here again
Archive.zip