meik.michalke at uni-duesseldorf.de
Fri May 12 14:46:14 UTC 2017
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
> 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
> >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
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:
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...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the kde-mac