[rkward-devel] [rkward-cvs] SF.net SVN: rkward-code:[4787] trunk/rkward/macports/kde

[Thomas Friedrichsmeier]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20140501/c7dfb03b/attachment.sig>