PyAlembic/Tests/CMakeList.txt BOOST error

[GoogleCodeExporter]

#What steps will reproduce the problem?
1. Attempt to configure build normally.

#What is the expected output? What do you see instead?
CMake Error at python/PyAlembic/Tests/CMakeLists.txt:66 
(GET_FILENAME_COMPONENT):

get_filename_component called with incorrect number of arguments

# What version of the product are you using? On what operating system?
Alembic 1.5.1
OSX Mavericks (10.9)

#Please provide any additional information below.
This is easily fixed by changing BOOST_PYTHON_LIBRARY to Boost_PYTHON_LIBRARY 
at line 66

Original issue reported on code.google.com by blackencino on 25 Oct 2013 at 8:02

[GoogleCodeExporter]

Original comment by miller.lucas on 25 Oct 2013 at 8:06

[GoogleCodeExporter]

Changing line 66 as suggested did not work for me.

Commenting out the line did work (or at least allows compilation of the library 
to proceed), but it makes me wonder what might have broken down the chain.

Original comment by Nick.Por...@gmail.com on 3 Nov 2013 at 5:35

[GoogleCodeExporter]

Nick, are you also compiling on OSX 10.9? Are either of you using the 
bootstrap? 

There are some case inconsistencies for the boost libs in the cmake files 
(Boost vs. BOOST), but I believe this one is set by the bootstrapscript on 
:268. 

Original comment by r...@rsgalloway.com on 4 Nov 2013 at 9:56

[GoogleCodeExporter]

I've never, ever been able to get the bootstrap to work. I just manually
add MYLIBRARY_ROOT variables to the top-level CMakeLists.txt whenever I
unpack a new version.  I also make a little "/usr/local"-esque depot where
I gather all the prerequisites, so I can use a single directory. It helps
me diagnose and prevent weird include-path clashes.  So, I add this (right
after the bootstrap mode code):

SET( DEPOT_ROOT /Users/encino/depot/bundles/DvlpNeeds/1.0.1-Oct23-2013/ )
SET( BOOST_ROOT ${DEPOT_ROOT} )
SET( ILMBASE_ROOT ${DEPOT_ROOT} )
SET( PYILMBASE_ROOT ${DEPOT_ROOT} )
SET( OPENEXR_ROOT ${DEPOT_ROOT} )
SET( HDF5_ROOT ${DEPOT_ROOT} )

Which seems to work for me. I am compiling on 10.9, with clang. I had to
explicitly force it to use clang by setting the environment variables:

setenv CC /usr/bin/clang
setenv CXX /usr/bin/clang++

I also have a CFLAGS env var, and a CXXFLAGS:

setenv CFLAGS "-fPIC -DPIC"
setenv CXXFLAGS "${CFLAGS} -std=c++11"

C

Original comment by blackencino on 4 Nov 2013 at 10:03

[GoogleCodeExporter]

> I also make a little "/usr/local"-esque depot where I gather all the 
prerequisite

This is similar to the idea behind the --dependency-install-root option in the 
bootstrap, and I use this every time.

> I've never, ever been able to get the bootstrap to work

Sorry to hear, but not terribly surprised. I've been able to make it work on 
mountain lion (also with clang), but haven't tested mavericks yet. Do you have 
any more information you can share? 

FWIW, here are my build notes
https://gist.github.com/rsgalloway/5835065

Original comment by r...@rsgalloway.com on 4 Nov 2013 at 10:12

[GoogleCodeExporter]

Can we learn anything from the CMake work that Piotr is doing with OpenEXR?
 It would be ideal if we could just get it to be as robust as autoconf
solutions for other libraries are. I don't think Alembic's needs are all
that unique.

Original comment by blackencino on 4 Nov 2013 at 10:14

[GoogleCodeExporter]

Yes, I am compiling for 10.9.

I couldn't get the bootstrap to detect that it was okay to build the Python 
bindings, possibly because Apple no longer ships the Python framework as part 
of the SDK. Bootstrap otherwise worked, except all the boost tests fail, and I 
had to tell it to skip them. I haven't spent time looking into why the boost 
test apps don't compile. One deviation from a typical build, is that I built 
boost with my own script since Mavericks doesn't ship with boost_python. 
Perhaps I have made an assumption here 
https://github.com/meshula/boost-build-club that doesn't match the bootstrap 
script's assumptions.

I manhandled the output of the bootstrap process to make that go, and to only 
generate 64 bit x86 builds, but was unable to coerce it into generating Xcode 
project files - it would only make make files. I'm pretty sure that's 
controlled by one of the Cmake control files, but I didn't pursue it.

The makefiles worked, and I got a working viewer, but I ran into troubles 
trying to get build settings that match build settings in my Xcode projects 
that need to include Alembic, so ultimately I whipped up an Xcode project file, 
copied the relevant settings into that, and am working with that.

I would say that Cmake will probably be frustrating for OSX users until they 
release a version that is Xcode 5 savvy.

For OpenEXR, I introduced a Mavericks_port branch to explore bypassing a cross 
platform build system and just using xcodeproj files directly, same as we did 
for Windows with vcproj's. It's infinitely simpler.... ./fullbuild.sh, and 
boom, done. I set that one up magically blit EXR into 
/usr/local/include/OpenEXR, and /usr/local/lib.

Original comment by Nick.Por...@gmail.com on 4 Nov 2013 at 10:33

[GoogleCodeExporter]

Original comment by miller.lucas on 11 Dec 2013 at 12:48

• Added labels: Component-Build