hi, Am Donnerstag 24 November 2011, 16:56:44 schrieb Thomas Friedrichsmeier: > > since r.xml conflicts with the kate port, i apply the patch above to > > remove it from installation. > > In the debian packaging, the files are first installed to a temporary > directory, then r.xml is removed from that, and then the archive is > created. I don't know, how macports works, but if the procedure is similar, > then this approach might be easier/cleaner than patching CMakeLists.txt.
it's a little different. MacPorts doesn't create archives to install, it works more like an automated "./configure && make && make install", where you define the specifics for each phase of the process in the portfile. you can then later create precompiled binaries, but they are more like the packaged result of a source compiling portfile like this one, so either way this is the basic build process. but as long as the CMake file doesn't change all the time, it works just fine. > (Otherwise, we could consider adding a cmake parameter to control whether > r.xml will be installed). that would be even more elegant, would result in a special install target, right? > Ok, so I guess the target state is: > /Applications/MacPorts/KDE4/rkward.app/Contents/Info.plist > /Applications/MacPorts/KDE4/rkward.app/Contents/MacOS/rkward (the usual > wrapper scripts) > /Applications/MacPorts/KDE4/rkward.app/Contents/MacOS/rkward.shell (?) > /opt/local/lib/kde4/libexec/rkward.rbackend > /opt/local/lib/kde4/libexec/rkward.frontend > > All others are probably ok. I don't really have a clue how to get there, > though. the *.shell scripts are created by cmake and include path/environment information. there's a lot of cmake magic going on anyway, and MacPorts has some defaults set on its own, my hope is we just need to figure out the right configure options without changing too much in the sources really. well, let's see... > > fetching the available packages list didn't bring up the dialog to > > chose a mirror, and when i closed the management dialog RKWard crashed > > completely. > > Well, that does not sound quite perfect, yet ;-). no, not really... in fact, there seems to be something odd going on with the whole R backend. you can even see in the screenshot that the R indicator is yellow, it never reaches a green state. this means, e.g., you can't use RKWard's R console, you'd just wait forever. if you then close RKWard, a window reminds you that there are R processes running and stopping them could cause data loss. R started in a console behaves as usual. can this perhaps be related to RKWard not being compiled as an X11 application (at least it looks like it), while the R port lacks Aqua support on Lion? [i could try to test that with an R binary package from CRAN instead of the port i used now, as the alternative R-framework port won't compile]. but not before tomorrow. 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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
