build instructions

[meik michalke]

Am Freitag, 12. Mai 2017, 18:37:44 CEST schrieb René J.V. Bertin:
> But you mention students ... shouldn't they rather be using the commandline
> or script files, you know, to get hands-on experience with what's going on
> behind those fancy dialogs? ;)

the concept of RKWard is that you can always see all the R code that will be 
run if you submit the dialog; there's a code window below the actual dialog, 
and the R code you see changes instantly when you change settings in the 
dialog. this gives people with no experience in programming a feeling for it. 
its not about hiding complexity, but to build a bridge for new users.

i think we also found an amazing way for more advanced users to extend 
RKWard's functionality. i wrote an R package called rkwarddev which lets you 
write new GUI dialogs in form of an R script and package the result as a 
simple R package to share with others. thomas did a great job designing RKWard 
as being plugin-based from the start (all shipped dialogs are actually plugins 
that are pre-installed).

> > everything from 5.6 onward should do -- says the webpage ;-)
> 
> I forgot, there's also a Qt56 port, if the LTS release is good enough for
> you.

downgrading to stock Qt 5.6 was the key! which means the instructions should 
either not just say "Qt >= 5.6" but rather "Qt == 5.6", or the configuration 
should check more carefully, given that Qt 5.8 obviously is no longer downward 
compatible with Qt 5.6.

but kate compiled fine and works well!

> As I said, I don't know if an installer package created with MacPorts will
> mess up an existing MacPorts install.

yet, it will. it will overwrite everything in its way without MacPorts 
noticing it. the policy to not make installers write to the standard MacPorts 
directory is explicitly demanded so in the MacPorts docs. it wasn't something 
we came up with ourselves ;-)

> > 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
> That's because the package is created to allow installing from scratch.
> Somewhere down the line a dependency claims a dependency on ffmpeg (that
> could well be libVLC or else phonon-backend-gstreamer), and there you go.

yes, i absolutely understand process behind it.

> You can do `port rdeps foo` to get a recursive tree of all dependencies,
> that allows you to figure out where the big unexpected (non-)dependencies
> come from. Sometimes you can get rid of them by installing their dependent
> with a variant.

i think the bundling mechanism in MacPorts doesn't really care so much about 
variants, it just creates a collection of the defaults.

> > 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...
> No (unless you want to be able to input audio or video data, maybe? 8-))
> Isn't there a way to build a package that contains only a specific port?
> You'd need to figure out how to create the required packages, and a script
> that installs them in the right order, but that's largely something you
> only have to do once.

i would like to explore the craft way an see where it leads. i'd rather only 
consider a script-driven workaround if that doesnt' work out.


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/20170513/113e5a74/attachment.sig>