[C++-sig] Re: Mac OS 10 success

[Rene Rivera]

[2003-05-23] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik666 at redshift-software.com> wrote:
>> These are the bjam equivalents with the current state of
darwin-tools.jam...
>> 
>> ### currently called as "c++" not "g++"
>> >g++
>
>Apple's current c++ (based on gcc 3.1) doesn't work. I am using g++ 3.3
>compiled from sources. How about renaming the toolset to
darwin-gcc-tools.jam?

Na, too much hasle for the outdated BBv1 ;-)

I'll just update the existing one... But I have a question about GCC in your
case. When you compile/install from sources where is it installed to? That
is how can I find it as opposed to the built in c++?

>>     ### <include>/Library/Frameworks... (It seems that python.jam would
need
>> to change to look here when the correspoding PYTHON_VERSION is set. That
is
>> setting the PYTHON_ROOT to
>> "/Library/Frameworks/Python.framework/Versions/$(PYTHON_VERSION)" )
>
>I obtain the -I path by looking at sys.executable and sys.version in
Python.
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/config.py?rev=1.5&content-type=text/vnd.viewcvs-markup
>I am not sure how this could fit into the bjam framework.

It would not. Is it standard, or required, for the Python build as framework
to go where you have it? If it is I can just use that and assume the Python
build does the right thing.

>> >Linking libboost_python.dylib (three commands):
>> 
>>     ### I'm fairly sure there are additional library path seetings here?
>
>Sorry, I don't understand what you mean here.

:-) In the current bjam toolset I have stuff for setting the load library
search path so that it finds other libraries.

>>     ### Yea, that's just what the DLL target does, except for...
>>     
>> >ld -dynamic -m -r -d -o libboost_python.lo
boost/libs/python/src/numeric.os
>> >boost/libs/python/src/list.os boost/libs/python/src/long.os
>....
>> >boost/libs/python/src/object_operators.os
>> >
>> >g++ -nostartfiles -Wl,-dylib -ldylib1.o
>> 
>>     ### <framework>/Library/Frameworks/... (this is currently put in as
>> <framework>Python, is that enough? Or is the complete path-spec needed?)
>
>I am not entirely sure I understand your question. Trial answer: I only
could
>get it to work when specifying the full path. My experiments with
>-L/Library/Frameworks/.../2.3 failed. Maybe because Python doesn't exist
with a
>..dylib extension?
>
>> >   -framework /Library/Frameworks/Python.framework/Versions/2.3/Python

It's a question between:
    -framework /Library/Framework/Python.framework/Version/2.3/Python
or
    -framework Python

It's my understanding that in the second case the OS will search for the
latest version, or something such. But perhaps being specific is best for
now. I'll put the full path in there just to get it working :-)

>>     ### I thought -bundle didn't take a value? (Currently only -bundle is
>> added)
>
>> > -bundle /Library/Frameworks/Python.framework/Versions/2.3/Python
>
>You are right, -bundle doesn't take a value. But the full
>/Library/.../2.3/Python path has to appear somewhere. Maybe this is most
>logical:
>
>g++ -w -bundle -bundle_loader
>/Library/Frameworks/Python.framework/Versions/2.3/
>Python -o libtbx/scitbx_boost/rational_ext.so
>scitbx/boost_python/rational_ext.o
>s -Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx
>-lscitbx_boost_pytho
>n -lboost_python /Library/Frameworks/Python.framework/Versions/2.3/Python
-lm

Ah, got it, it's just the link to the dylib bundle (without the .dylib). You
would think the -bundle_loader... option would be sufficient :-(

>> So as far as I can see the only changes needed are in python.jam, and
>> possibly the "-bundle" option in the toolset.
>
>If you modify the toolset and check it in I will try it out. I don't think
>there is a reason to be conservative since the old one never worked for
>compiling and linking all Boost.Python regression tests AFAIK, due to bugs
and
>limitations of compilers older than gcc 3.3.

I'll do the modifications and check it in. My concerns where in modifying
python.jam, without really being able to test it, as that affects all python
builds, not just the darwin one.


-- grafik - Don't Assume Anything
-- rrivera at acm.org - grafik at redshift-software.com
-- 102708583 at icq