Xvfb MIA

[Jack Howarth]

Rene,
      My point was that it is not uncommon for cran modules to contain
code that triggers access of the X server during the execution of 'R
CMD install'. For example, we see this behavior with the analyzefmri,
atelier, cairodevice, cluster fly, clustersim, fair, fmri, fso,
gwidgetsrgtk2, gwidgetstcltk, met sizer, nmrs, pbsmodelling, pkgraph,
pkmodelfinder, playwith, r2stats, rcmdr, rcmdrplugin.doby,
rcmdrplugin.ma, reshapegui-, rpanel, titan and tkrplot cran modules.
      We also sometimes have to resort to xvfb-run in our InfoTest,
which runs make check during package validation, on python modules
like pygtk2-gtk as well as on 11 different perl modules. All of these
are easily solved provided a Xvfb which functional is available for
use with a fairly simple xvfb-run script.
                  Jack



On Thu, Feb 12, 2015 at 1:12 PM, René J.V. <rjvbertin at gmail.com> wrote:
> On Thursday February 12 2015 11:58:33 Jack Howarth wrote:
>>Jeremy,
>>    So I take it that it is impossible to use MacPort's Xvfb without
>>abandoning the use of the Xquartz server in /opt/local/X11? That is
>>rather unfortunate as my experience in packaging over 500 cran modules
>>for fink was that at least 26 needed to have R CMD INSTALL passed
>>through xvfb-run as those trigger accesses to the X server.
>>         Jack
>
> Jack, it's been a few years since I last used R, but even then it already had sufficient support for native graphics. In fact, I had to trick it into using Tk/X11 (because that worked better for me).
> So what's that requirement on X11 of those packages? And maybe more to the point: CRAN has its own packaging scheme as far as I remember (incl. a package manager directly available through the R gui); is it really useful to encumber MacPorts with  "over 500 cran modules" ?
>
> R.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev