[R-SIG-Mac] [Bioc-devel] how to create my own repository of mac os x binaries?

[Simon Urbanek]

[I'm CCing this to SIG-Mac as this may be of global interest]

On May 16, 2006, at 9:25 AM, Seth Falcon wrote:

> stefano iacus <stefano.iacus at unimi.it> writes:
>
>> Please, take care that the new R binary for OS X is Universal,  
>> which means you have to consider also a universal build of the  
>> packages.
>
> Two questions about this:
>
> Is it possible to create Universal binaries on the PPC-based macs?
>

Out-of-the-box, no. Theoretically, yes. Practically, possibly  
(untested).

The only problem (AFAICS) is that Tiger installed on PPC machines  
doesn't contain Intel system libraries. Although the gcc we are  
providing can compile i686 binaries on ppc machines, the final  
linking step fails, because the system libraries are missing. So the  
solution could be to add i686 system libraries to ppc Tiger.

The 'official' way to do it is to use Xcode 10.4u SDK, but R is not  
aware of this concept which is local to Xcode. (Idea: lipo the i686  
system libraries from the SDK to the system)

> Won't CRAN-style repositories continue to support separate  
> locations for ppc and intel OSX packages?

Sort of. Although you could do that, it doesn't make much sense,  
because if you had separate binary packages, you may as well create  
the universal one by copying their contents into one directory.  
However, CRAN R is universal, so you cannot offer different kind of  
packages. This is how it works in detail:

Package installation:
- requests file from the current architecture's directory (e.g. ppc)
Repository (convention used by CRAN, but not enforced in any way):
- all universal packages are in `architecture' directory "universal"
- "ppc" and "i686" point symlinks to "universal"
Universal packages are tagged as "Built: universal-apple-darwinXXX"

Since even the universal R is looking for arch-specific packages, you  
cannot have two different builds of R (this was never supposed to  
work). You can, however, opt to create package for the universal R  
that contains binary for only one architecture. You could put this  
binary in the corresponding 'ppc' or 'i686' tree. In that case it  
will appear only on the appropriate architecture.


>   If so, creating universal binaries seems a convenience for the  
> package producer rather than end users.
>

It depends - "universal" R has the property that it works as-is on  
either platform. Single-arch packages don't, so if you're using the  
same image or hd to boot different machines, only universal package  
will work. Therefore and given the fact that if you have package for  
each arch, you effectively have the universal binary, you're  
discouraged to create individual packages.


> We are finding some difficulties in building universal binaries for  
> packages that depend upon external libraries and it isn't clear to  
> me that it won't be easier to build ppc and intel packages  
> separately (assuming one has access to both types of systems).
>

You can, of course, do that and create the universal package.  
Universal package is effectively nothing else but

R_ARCH=/i686 build foo for i686 in i686/foo
R_ARCH=/ppc build foo for ppc in ppc/foo
cp -r ppc/foo/libs/ppc i686/foo/libs/
pack foo in i686 and you have universal package

I doesn't matter whether you do that on a single machine or you use  
two. (Well-kept secret: universal R is built this way in order to be  
able to run make check natively. However, the packages are not).

As of external libraries - it's (mostly) not a problem, either,  
because you can simply lipo them together, even if you build them on  
another machine.

Cheers,
Simon