build instructions

[René J.V. Bertin]

On Saturday May 13 2017 00:35:44 meik michalke wrote:

>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 hear you. Students aren't just any kind of "new users" though, but you're the expert here :)

>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.

I still think your install was somehow corrupted, OR Qt 5.8.0 had a flaw. Come to think of it, there was indeed a Qt 5.8 issue that prevents building among others the Designer plugins. That might explain why the UI plugin isn't there.

So if anything, the instructions are incomplete in that they don't list known issues with stock Qt versions.

A known issue with Qt 5.6 LTS: it doesn't have any of the newer components, which means applications requiring newer QML functionality won't build.

>yes, i absolutely understand process behind it.

My bad, I hadn't realised you're the current maintainer of the RKWard port for KDE4 :)

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

I recall that I always aborted attempts because it wanted to start building everything. Is that indeed what happens? In that case you'd be right that you don't have full control over install variants of indirect dependencies, but it would be a bug if it doesn't respect variants of the target and any requirements that imposes on dependencies. You might also be able to use something like -x11 (turning off a variant) for a KDE4 package to disable X11 variants down the dependency tree. I never tried, but variant specifications ought to be sent down the tree during the install process, and the installer/bundler is built on that from what I can remember.
BTW, do you also get the build-only dependencies into the installer?

What might be possible and a nice GSoC project is to use the information and functions already used by the rev-upgrade feature:
1- list all the target port's binaries
2- fetch the recursive list of their actual dependencies
3- build the list of corresponding ports
4- build the list of all runtime dependencies
5- repeat steps 1-3 for all of these that aren't already in the current list of ports to install
6- bundle those ports from the current install.

Bundling could use the software image but could also just scrape all installed files into a new archive. If using the software images it should be possible to create an installer that installs those into an existing MacPorts installation if one is present (they're the same kind of images you get from the build bots).

 
>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.

I found a moment to install the current R port; it took less than 10 min to build since I already had all dependencies installed. I also have a draft port:kf5-rkward that builds but needs polishing (like a small patch to install an app icon).

R.