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. Cheers, Simon ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel