[Pythonmac-SIG] setup.py for Numeric/Numarray

[Bob Ippolito]

Two things:

1) Apple can't (or rather, won't ever) change their framework location.
2) Darwin might be Darwin and not Mac OS X, which won't have vecLib.
3) Checking for both is silly, because you won't reasonably ever have 
the path to vecLib on a non-Darwin platform.. and if you somehow do, 
it'll probably work anyway.

I can give more flexible code with regard to locating frameworks in an 
identical manner to what gcc and dyld do, but that is only going to be 
applicable if you work at Apple, or you are building against an SDK, 
neither of which happen very often in practice.  With regard to 
building against a SDK, the API used by Numeric that is provided by 
vecLib isn't going to change, ever, unless Numeric wants more stuff 
that is provided only in OS X 10.4+, for example.  This would be an 
issue when and if it happens, but in that case you would probably link 
against the NEW name (Accelerate.framework).  I'm not sure if the 
vecLib API is supported by OS X 10.1, but someone else is going to have 
to care about that because I sure don't.

Alternate linkers isn't really a concern because the three command-line 
compilers that matter probably all support the -framework flag.  
Apple's GCC (obviously..) and IBM's XLC (according to Robert) certainly 
do, and more likely than not, MetroWerks CodeWarrior also does (someone 
else would have to confirm this).  If Fink or Gentoo ships some purely 
GNU-based compiler/linker that doesn't support -framework, I'd consider 
that a bug.  I'm not sure how they'd get many things to compile 
correctly without it, unless they're emulating it by specifying paths 
directly to the Mach-O MH_DYLIB files 
(/System/Library/Frameworks/vecLib.framework/vecLib, for example) PLUS 
using non-framework-style header paths everywhere, since 
<vecLib/vecLib.h> would never work if you -I to anywhere in the 
framework tree.  Does an unpatched GNU toolchain even understand Mach-O 
in the first place?  Most likely a non-issue in any case, but I'm not 
about to Finkify any machine to test that theory.

In summary, I wrote the patch in that way for the specific reason of 
doing it as correctly as possible without overcomplicating things.  I 
hope that people would trust that I know what I'm doing.

[not cross-posted because the message I'm replying to isn't 
cross-posted, too lazy to figure out where it should be CC'ed to]

-bob

On Nov 22, 2004, at 10:08 PM, Chris Barker wrote:

> Hi all,
>
> Bob's patch to the Numeric setup.py made it's way to the numaray CVS, 
> and there is a little discussion about improvements. I really don't 
> know what to say but if some if the OS-X experts (Bob and Jack, 
> anyway!) on this list could weigh in, the would be great. Here is a 
> consolidation of the thread:
>
> Andrea Riciputi wrote:
>> I've noticed your patch for MacOS X, and I think that a better 
>> solution  should use sys.platform instead of a path search, since 
>> Apple could  always change its framework location. I've also removed 
>> the  VECLIB_PATH/Headers from the include path because AFAIK Apple 
>> gcc  already knows where to search for the vecLib framework. Here it 
>> is a  diff output between my addons.py and the CVS one.
>
> <trimmed by me: chb>
>
>>> !     if sys.platform == "darwin":
>>> !         lapack_include_dirs =   
>>> ["Packages/LinearAlgebra2/Src",'Include/numarray']
>
>>> -         lapack_link_args = ['-framework', 'vecLib']
>
>>> !     VECLIB_PATH = '/System/Library/Frameworks/vecLib.framework'
>>> !     if os.path.exists(VECLIB_PATH):
>>> !         lapack_link_args = ['-framework', 'vecLib']
>>> !         lapack_include_dirs.append( os.path.join(VECLIB_PATH,  
>>> 'Headers'))
>>>           lapack_libs = []
>>>           lapack_dirs = []
>
> Todd Miller wrote:
>
>> Not to look a patch-horse in the mouth, but IMHO,  the sys.platform 
>> idea
>> is good but the VECLIB_PATH elimination maybe less so.  The reason I
>> question the VECLIB_PATH change is that we're removing explicit and
>> generally harmless extra information in exchange for two assumptions: 
>> (1) gcc knows the path already  (2) the numarray Mac user is using 
>> gcc. Other opinions?  Mac users please speak up if you think the  
>> VECLIB_PATH
>> change is a good one or it won't get done.
>
> Andrea Riciputi wrote:
>> I see your point but AFAIK the links option "-framework vecLib" will 
>> work *only* with Apple gcc (ld) and Apple gcc (ld) does know where 
>> frameworks are. From Apple ld man page:
>>> -framework name[,suffix]
>>>     Specifies a framework to link against.  Frameworks  are  dynamic
>>>     shared  libraries,  but  they are stored in different locations,
>>>     and therefore must be searched for differently. When this option
>>>     is  specified,  ld  searches for framework `name.framework/name'
>>>     first in any directories specified with the -F option,  then  in
>>>     the  standard  framework  directories /Library/Frameworks, /Net-
>>>     work/Library/Frameworks,  and  /System/Library/Frameworks.   The
>>>     placement  of the -framework option is significant, as it deter-
>>>     mines when and how the framework is searched.  If  the  optional
>>>     suffix is specified the framework is first searched for the name
>>>     with the suffix and then without.
>>> -Fdir
>>>     In Apple's version of GCC only, add the directory dir to the head
>>>     of the list of directories to be searched for frameworks.
>>>
>>>     The framework search algorithm is, for an inclusion of
>>>     <Fmwk/Header.h>, to look for files named 
>>> path/Fmwk.framework/Head-
>>>     ers/Header.h or path/Fmwk.framework/PrivateHeaders/Header.h where
>>>     path includes /System/Library/Frameworks/ /Library/Frameworks/, 
>>> and
>>>     /Local/Library/Frameworks/, plus any additional paths specified 
>>> by
>>>     -F.
>
> Robert Kern wrote:
>> IBM's xlc will also find the appropriate framework, but as you can 
>> see this is only a link-time option and has nothing to do with 
>> finding headers.
>> Using
>>   #include <vecLib/vecLib.h>
>> will find the appropriate header without any command-line options. 
>> Using
>>   #include <clapack.h>
>> will not.
>> Fortunately, neither one is used nor needed by lapack_litemodule.c, 
>> so for this case, no include-path needs to be specified.
>
> If you don't want to post tot he NumPy list directly, I'd be glad to 
> forward comments on.
>
> -Chris
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>                                     		
> NOAA/OR&R/HAZMAT         (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig