Hi Simon,
On Fri, Sep 9, 2011 at 5:32 PM, Simon Urbanek
<simon.urba...@r-project.org> wrote:
>
> On Sep 9, 2011, at 10:30 AM, Steve Lianoglou wrote:
>
>> Hi Simon, Prof. Ripley, and Dirk,
>>
>> First: thanks again for the tips, it's great to have some of the "top
>> bRass" providing this type of help.
>>
>> Last (few) comments in line:
>>
>> On Fri, Sep 9, 2011 at 9:41 AM, Simon Urbanek
>> <simon.urba...@r-project.org> wrote:
>>> On Sep 9, 2011, at 8:36 AM, Prof Brian Ripley wrote:
>>>> On Thu, 8 Sep 2011, Steve Lianoglou wrote:
>>
>> [snip]
>>
>> About the architecture thing:
>>
>>>>> Ok, sorry for being imprecise. Let's see if we can figure out what it
>>>>> is (more precise details are at the bottom of the email). I see x86_64
>>>>> on every 64bit machine I touch (linux or mac), so I thought they were
>>>>> interchangeable (as names).
>>>>
>>>> Not so. That's not what Windows uses (it mainly uses x64, sometimes amd64
>>>> or x86-64, almost never x86_64), and although it is what Solaris uses,
>>>> your Linux x86_64 assembler (presumably GNU) will not work there.
>>>>
>>>
>>> Moreover not all 64-bit machines are x86_64/amd64 - there is ppc64, Sparc,
>>> MIPS64, IA64, ... which was my point about this having to do with a very
>>> particular machine type (and my suspicion involving asm was correct ;)) and
>>> not 64-bit architectures in general.
>>
>> Right, of course ... as soon as you mentioned ppc64, the distinction
>> you folks were trying to point out was immediately clear, thanks.
>>
>> [snip]
>>
>> About the configure/autoconf testing thing:
>>
>>>> You try to compile the crucial fragament of code in configure: there are
>>>> lots of examples of that in the R sources (mainly in the m4 directory).
>>>
>>> Yes, that is the right thing to do. It's only a few lines of configure.in
>>> if you want to use autoconf, but if you don't, it's still fairly easy in
>>> pure shell code, just a bit more legwork.
>>
>> OK, thanks for that, too.
>>
>> So, last question here -- say I catch this error condition during the
>> configure (or shell) check code, and I realize that some bit of code
>> won't work on this machine type.
>>
>> How do I signal to R's build/compile process to "error out" on the
>> package build proces, but just move on to the next arch/machine-type
>> it should try to compile?
>>
>> I mean: I can imagine how one could catch an error during the compile
>> test and then define some var that an `#ifdef SOMETHING` could be used
>> in my codebase to do one thing or the other, but in this case I'm not
>> trying to direct the compiler down a different codepath that will work
>> for the machine type (for now), I just want it to give up on the
>> current build and try the build for the next machine-type in line.
>>
>
> You can't. Your packages either builds or not. And as you should know by now
> there is no "next matching-type" in line since configure guarantees just one
> arch.
>
> So you have two options:
>
> a) fail on unsupported architecture. That means only if the architecture is
> supported there will be a binary. Simple and clean.
>
> b) let configure detect the support and flag it. Then you can #ifdef your
> code and create a stub that simply calls Rf_error("unsupported
> architecture"). In fact in your particular case you could even possibly get
> away with #if __x86_64__ and no configure. It's less clean because the user
> doesn't know that your package doesn't work and may be clumsy if you have
> several R entry points.
Ah! I didn't even think of throwing an Rf_error() from within the code
that would fail, thanks.
It's not pretty but it does the trick for now.
Thanks again for all the help,
-steve
--
Steve Lianoglou
Graduate Student: Computational Systems Biology
| Memorial Sloan-Kettering Cancer Center
| Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
