build instructions

[meik michalke]

Am Freitag, 12. Mai 2017, 15:51:58 CEST schrieb René J.V. Bertin:
> On Friday May 12 2017 14:15:28 meik michalke wrote:
> >compiled for (at least major release-wise). but it compiles with stock
> >releases from CRAN, i.e., you don't have to use MacPorts R. that is
> >actually
>
> Hmm, a MacPorts package will need to depend on the MacPorts R.

we *are* currently using MacPorts to build our bundle packages, i.e., the 
*.pkg files you get from downalod.kde.org are MacPorts builds linked against 
stock R from CRAN. the main reason for that is that most R users already have 
it installed, so we didn't want to ship another R environment. that would be a 
mess (like, how do you explain where to install R packages etc.). 

> I don't actually remember which R gui I used back in the day. Nothing that
> had big dependencies like Qt, I think there was (is?) a native one for Mac.

R comes with a rather primitive GUI itself, but most people are probably using 
RStudio today, because it's quite popular. but RStudio is more an IDE, whereas 
RKWard combines that with a GUI (with plugin support for even more statistical 
dialogs).

> >can i mix Qt from MacPorts with craft just like that?
> 
> Presuming craft can work with any Qt install then yes. You'll have to point
> it to the where MacPorts installs the stuff but I guess that's not any
> different with other kind of Qt installs.

sounds reasonable. i'll give it a try, but before i do i'll probably try and 
reinstall Qt, just to check that.

> The Qt5 port currently in MacPorts is still at 5.7.1 but is "stock" with
> just a few bug fixes.

everything from 5.6 onward should do -- says the webpage ;-)

> If you are now running into issues with craft that might mean that it
> hasn't been properly tested on Mac, and your experience could thus be
> valuable.

yeah, that's why i'm here.

> >if it's possible to build the kf5 version of RKWard with MacPorts *and* get
> >a much smaller bundle in the end, i'm all for it. for me building an
> >installable package in the end is the most important goal here.
> 
> Well, MacPorts does have support for creating installer dmg images. I've
> never really tried them, but I think they create full installers that
> recreate the whole /opt/local as far as needed for a given product.

yes, that's what we do. the official policy is to not use /opt/local for 
packages, because that might mess up an actual MacPorts installation. our 
packages install to /opt/rkward.

but the thing is, MacPorts puts literally everything into the bundle that is a 
dependency of dependencies, that's how we end up with >>1GB for an installed 
package. for just using RKWard, clearly only a fraction of that is needed, and 
i've actually already removed ports from the bundle semi-manually to make it 
smaller. e.g., we're pretty confident we don't need ffmpeg for statistics...

you might like to have a look at the build script i'm using for setting things 
up, building and bundling the app:
https://cgit.kde.org/rkward.git/tree/macports/update_bundle.sh?h=releases/
0.6.5

so, i do have some experience with creating packages with MacPorts, it's just 
the handling of dependencies that would need a lot of improvement.


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  institut f"ur experimentelle psychologie
  abt. f"ur diagnostik und differentielle psychologie
  heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20170512/3858d3e3/attachment.sig>