Hi, On Thursday 01 May 2014 17:04:47 meik michalke wrote: > Am Donnerstag, 1. Mai 2014, 10:16:04 schrieb Thomas Friedrichsmeier: > > good. So does that mean, we don't have to depend on a particular compiler > > version anymore? > > well, it looks like it. all ports we rely on seem to have fixed the compiler > dependecies on their part, so the MacPorts defaults do well now!
Cool. One thing to watch out for is avoiding any risk of incompatibilities with binary R packages, if those are using a specific compiler. AFAIR the Macports R defaults to source packages (for the same reason), but when bundling with binary R, we should probably play it safe. From the way I read the Portfile that's what you're doing, too. > > > we would need another patch for the stable binary subport, because the > > > configure argument R_LIBDIR is being ignored, so RKWard doesn't find the > > > rkward package and crashes ;-) however, if that doesn't become a part of > > > MacPorts anyway, we shouldn't have to bother. > > > > Yes, let's ignore this for now, and leave it for 0.6.2. (BTW, one other > > thing that I really want to fix for 0.6.2 is the troubles running from > > paths with spaces on Windows). > > is that a matter of quoting all path references internally? Essentially. And the only issue I am aware of concerns startup. However, don't be fooled into thinking it's a trivial issue on Windows, to invoke an app with spaces in the path _and_ potentially quotes in some of the arguments... Well I started working on it, locally, and I'm confident it won't be _that_ much more work. But to give you an idea of my desparation: My current approach involves URL-encoding (%-encoding) all arguments, inside the startup wrapper, then unencoding them in the frontend. > > Two more suggestions: I guess the main use-case for rkward-binary is going > > to remain building the bundles. It _may_ make sense to have a third > > Portfile just for rkward-binary, and adjust that to point to the correct > > SVN-location (trunk or release_branch) as needed > > i thought about something like that, too. allthough i would suggest to move > the binary subport completely into the rkward-devel port, so we have "our" > portfile and a clean one for MacPorts. the main difference between both > portfiles at the moment is wheter a specific SVN revision is set or not, > that should be easy to toggle within the devel portfile. i hope we can > avoid to maintain three portfiles that way. True. > > (could that even be implemented as a variant?). > > i'd go for different subports. Just a thought for later: _If_ that would be possible, perhaps that would be a good way for keeping an equivalent of the "rkward-devel" option in Macports. > i didn't manage to bundle varaints, but > that's > no problem with subports. hm... which reminds me: > > Now that the -debug variant does not need any explicit configure arguments > > anymore, it does look somewhat pointless, indeed. Telling bug reporters to > > > > sudo port install rkward +debug > > sudo port install valgrind > > > > should not be too much more scaring than just the first line. > > if we also want to be able to distribute debug *bundles*, it will have to > become a subport again. Ok. Well, as long as the rkward-devel Portfile is not going to be in Macports, we're free to do all those forbidden things, there... Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
