Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#33649 closed update (fixed)

cgal update 3.9 -> 4.0

Reported by: mamoll (Mark Moll) Owned by: Veence (Vincent)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: seanfarley (Sean Farley), raphael-st (Raphael Straub)
Port: cgal

Description

Trivial update. Licensing has changed. Eigen3 is now preferred over some other low-level dependencies. See http://www.cgal.org/Manual/latest/doc_html/installation_manual/Chapter_installation_manual.html#Section_4

Attachments (5)

patch-Portfile.diff (1.1 KB) - added by mamoll (Mark Moll) 8 years ago.
Portfile-cgal-qt4-debug.patch (2.2 KB) - added by seanfarley (Sean Farley) 8 years ago.
Fix livecheck and Qt4 checks; add debug
patch-cmake-modules-CGAL_CreateSingleSourceCGALProgram.cmake.diff (336 bytes) - added by mamoll (Mark Moll) 8 years ago.
Portfile.diff (3.9 KB) - added by raphael-st (Raphael Straub) 8 years ago.
Portfile_1.diff (943 bytes) - added by raphael-st (Raphael Straub) 8 years ago.

Download all attachments as: .zip

Change History (40)

Changed 8 years ago by mamoll (Mark Moll)

Attachment: patch-Portfile.diff added

Changed 8 years ago by seanfarley (Sean Farley)

Fix livecheck and Qt4 checks; add debug

comment:1 Changed 8 years ago by seanfarley (Sean Farley)

Sorry about high highjacking this thread; I was about to create a new ticket that updated cgal to 4.0 as well. I see that you added a dependency on eigen3 but from the cgal manual, eigen is only recommended over taucs, which wasn't a dependency before, so maybe eigen3 could be a variant?

comment:2 Changed 8 years ago by seanfarley (Sean Farley)

Cc: sean.michael.farley@… added

Cc Me!

comment:3 Changed 8 years ago by mamoll (Mark Moll)

The demos don't compile. First, I needed to change compiler to this:

configure.compiler llvm-gcc-4.2

Even with this change there appear to be some rpath errors. Also, all kinds of cmake cruft get installed.

comment:4 in reply to:  3 Changed 8 years ago by seanfarley (Sean Farley)

Replying to mmoll@…:

The demos don't compile. First, I needed to change compiler to this:

configure.compiler llvm-gcc-4.2

I am trying to compile the demos now. At the very least, they'd need

requires qt4

I don't see off the top of my head why llvm-gcc-4.2 needs to be explicitly set? Ah, I see I got rid of the patch-src-config file perhaps a little too early. I'm trying to compile and test now.

Even with this change there appear to be some rpath errors. Also, all kinds of cmake cruft get installed.

Hmm, what do you mean? There isn't much difference between your patch and mine except for the eigen3 dependence and the qt4 variant I added.

comment:5 Changed 8 years ago by seanfarley (Sean Farley)

Ok, I think I've figured out why the executables in demo and examples aren't linked correctly. It's because there is no CMAKE_INSTALL_NAME_DIR variable set in the cmake files ... which still doesn't fix this problem because demos and examples have no 'install' target. CGAL really expects these demos and examples to be built *after* CGAL has been installed (post-activate). In light of this, I think the way to go is to remove the demos variant and keep the qt4 variant. If a user wants to build a demo, then they can download the source. Unless there is a particular reason that building demos is needed for macports? Either way, I can send a new patch after I get some feedback.

comment:6 in reply to:  1 Changed 8 years ago by raphael-st (Raphael Straub)

Version: 2.0.4

Replying to sean.michael.farley@…:

I see that you added a dependency on eigen3 but from the cgal manual, eigen is only recommended over taucs, which wasn't a dependency before, so maybe eigen3 could be a variant?

In fact, CGAL does not use the eigen3 port as it needs at least Eigen 3.1, which is a development version that MacPorts does not provide yet. So, I would remove the dependency on eigen3 until Eigen 3.1.0 or later is in MacPorts.

comment:7 Changed 8 years ago by raphael-st (Raphael Straub)

Cc: raphael@… added

Cc Me!

comment:8 in reply to:  5 ; Changed 8 years ago by raphael-st (Raphael Straub)

Replying to sean.michael.farley@…:

Ok, I think I've figured out why the executables in demo and examples aren't linked correctly. It's because there is no CMAKE_INSTALL_NAME_DIR variable set in the cmake files ... which still doesn't fix this problem because demos and examples have no 'install' target.

I discovered that CGAL_INSTALL_CMAKE_DIR should be a path relative to ${prefix}. So it should be -DCGAL_INSTALL_CMAKE_DIR="lib/cmake", which works for me.

A new patch is attached.

comment:9 Changed 8 years ago by raphael-st (Raphael Straub)

Keywords: haspatch added

comment:10 Changed 8 years ago by Veence (Vincent)

I’m definitely way behind you on this update, so when you think you have reached a suitable Portfile, tell me and I will. Commit it. Thanks! Vince

comment:11 in reply to:  8 ; Changed 8 years ago by seanfarley (Sean Farley)

Replying to raphael@…:

Replying to sean.michael.farley@…:

Ok, I think I've figured out why the executables in demo and examples aren't linked correctly. It's because there is no CMAKE_INSTALL_NAME_DIR variable set in the cmake files ... which still doesn't fix this problem because demos and examples have no 'install' target.

I discovered that CGAL_INSTALL_CMAKE_DIR should be a path relative to ${prefix}. So it should be -DCGAL_INSTALL_CMAKE_DIR="lib/cmake", which works for me.

Ah, nice!

A new patch is attached.

This still doesn't fix the rpath issue with demos and examples for me. One way we could fix it is to use 'otool -L' on all the executables, match the ${worksrcpath} variable, parse the libraries it links to, then use 'install_name_tool' to change it; but that seems like overkill since cmake will do this automatically if demos was listed as 'installable'. Do we really want the demos variant that much?

comment:12 Changed 8 years ago by mamoll (Mark Moll)

Wouldn't it be better to patch the CGAL CMakeLists.txt to install the demos? The cmake portgroup would then automatically fix the rpath?

comment:13 in reply to:  11 ; Changed 8 years ago by raphael-st (Raphael Straub)

Replying to sean.michael.farley@…:

This still doesn't fix the rpath issue with demos and examples for me. One way we could fix it is to use 'otool -L' on all the executables, match the ${worksrcpath} variable, parse the libraries it links to, then use 'install_name_tool' to change it; but that seems like overkill since cmake will do this automatically if demos was listed as 'installable'.

Could you please give me one example of an otool output that has a wrong rpath? I cannot reproduce your problem here on Snow Leopard, i386, Xcode 4.2.

comment:14 in reply to:  12 Changed 8 years ago by seanfarley (Sean Farley)

Replying to mmoll@…:

Wouldn't it be better to patch the CGAL CMakeLists.txt to install the demos? The cmake portgroup would then automatically fix the rpath?

If we *really* want to keep demos then, yes, it'd be much better to patch the CMakeLists files. I tried to look at that last night but got busy with other projects. Anyone got the time to patch those up?

comment:15 in reply to:  13 ; Changed 8 years ago by seanfarley (Sean Farley)

Replying to raphael@…:

Could you please give me one example of an otool output that has a wrong rpath? I cannot reproduce your problem here on Snow Leopard, i386, Xcode 4.2.

'otool -L /opt/local/share/demo/AABB_demo/AABB_demo' should do the trick. Of course, it takes something like 2 hours to build on my laptop, so I have been working with the CGAL-4.0 tarball in another directory (with the patches from macports, of course). It shouldn't be too hard to patch the CMakeLists.txt to have a 'make install' work for demos but testing this port takes sooooo long

comment:16 in reply to:  15 ; Changed 8 years ago by raphael-st (Raphael Straub)

Replying to sean.michael.farley@…:

'otool -L /opt/local/share/demo/AABB_demo/AABB_demo' should do the trick. Of course, it takes something like 2 hours to build on my laptop, so I have been working with the CGAL-4.0 tarball in another directory (with the patches from macports, of course).

Are you sure that you used all cmake options from the cmake portgroup?

This is what I get with the CGAL 4.0 beta compiled with MacPorts (The CGAL 4.0 release is still compiling, but the examples compiled so far have the right rpaths.):

$ otool -L /sw/clients/i386_darwin/share/cgal/demo/AABB_tree/AABB_demo
/sw/clients/i386_darwin/share/cgal/demo/AABB_tree/AABB_demo:
	/sw/clients/i386_darwin/lib/libCGAL_Qt4.9.dylib (compatibility version 9.0.0, current version 9.0.0)
	/sw/clients/i386_darwin/lib/libCGAL.9.dylib (compatibility version 9.0.0, current version 9.0.0)
	/sw/clients/i386_darwin/lib/libgmpxx.4.dylib (compatibility version 7.0.0, current version 7.4.0)
	/sw/clients/i386_darwin/lib/libmpfr.4.dylib (compatibility version 6.0.0, current version 6.0.0)
	/sw/clients/i386_darwin/lib/libgmp.10.dylib (compatibility version 11.0.0, current version 11.4.0)
	/sw/clients/i386_darwin/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/sw/clients/i386_darwin/lib/libQtOpenGL.4.dylib (compatibility version 4.7.0, current version 4.7.4)
	/sw/clients/i386_darwin/lib/libQtGui.4.dylib (compatibility version 4.7.0, current version 4.7.4)
	/sw/clients/i386_darwin/lib/libQtCore.4.dylib (compatibility version 4.7.0, current version 4.7.4)
	/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/sw/clients/i386_darwin/lib/libQtScript.4.dylib (compatibility version 4.7.0, current version 4.7.4)
	/sw/clients/i386_darwin/lib/libQtXml.4.dylib (compatibility version 4.7.0, current version 4.7.4)
	/sw/clients/i386_darwin/lib/libQGLViewer.2.dylib (compatibility version 2.3.0, current version 2.3.12)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

/sw/clients/i386_darwin is the custom prefix of my MacPorts installation.

comment:17 in reply to:  16 ; Changed 8 years ago by seanfarley (Sean Farley)

Replying to raphael@…:

Are you sure that you used all cmake options from the cmake portgroup?

Aha, good catch! I was afraid of this happening >_< ... but then why were there errors before reported by mmoll (and that I saw in the check done by macports itself)?

comment:18 in reply to:  17 ; Changed 8 years ago by raphael-st (Raphael Straub)

I think the best way to test new/updated ports is to put the Portfile into the current directory and the patches into ./files and to use port <action> without any portname. Or just use a local Portfile repository.

By the way, the cmake portgroup already has a debug variant. Do we really need to override this variant?

comment:19 in reply to:  18 Changed 8 years ago by seanfarley (Sean Farley)

Replying to raphael@…:

I think the best way to test new/updated ports is to put the Portfile into the current directory and the patches into ./files and to use port <action> without any portname. Or just use a local Portfile repository.

Yes, I usually do this but after building cgal a few times, I wanted a < 10 min way to see if the rpath was built correctly.

By the way, the cmake portgroup already has a debug variant. Do we really need to override this variant?

I would love to have a global variant definition that would maintain debug symbols but nothing seems to preserve the debug symbols kept in .dSYM except for running dsymutil manually (before the .o's are deleted)

eval exec dsymutil [glob ${destroot}${prefix}/lib/*.dylib]

Maybe the above could test for the existence of .dylib's then run the command, and that could be sent as another patch to cmake portgroup?

comment:20 Changed 8 years ago by raphael-st (Raphael Straub)

I moved the use of the qt4 portgroup from the demos to the qt4 variant and added configure.args-delete -DCMAKE_BUILD_TYPE=Release to the debug variant like in the cmake portgroup.

The updated Portfile patch that works for me (with the demos variant) on Leopard (powerpc) and Snow Leopard (i386 and x86_64) is attached.

comment:21 Changed 8 years ago by mamoll (Mark Moll)

I need to change the compiler to this: configure.compiler llvm-gcc-4.2 with raphael's patch to comple the demos variant. Even then, some of the demos are broken, because they expect plugins to be installed in /opt/local/lib. For example, this is what happens for me:

/opt/local/share/cgal/demo/Surface_reconstruction_points_3/Point_set_demo
dyld: Library not loaded: /opt/local/lib/libPS_demo_scene_item.dylib
  Referenced from: /opt/local/share/cgal/demo/Surface_reconstruction_points_3/Point_set_demo
  Reason: image not found
Trace/BPT trap: 5

Patching the CMakeLists file is probably the right way to go, but that's a pain. You can probably fix the programs without plugins using the attached patch for CGAL_CreateSingleSourceCGALProgram.cmake (untested). Perhaps the demos with plugins can be disabled?

comment:22 in reply to:  21 ; Changed 8 years ago by seanfarley (Sean Farley)

Replying to mmoll@…:

I need to change the compiler to this: configure.compiler llvm-gcc-4.2 with raphael's patch to comple the demos variant.

I wonder why you need to change the compiler? Is it the way you compiled qt4? For me, raphael's patch compiled but still has the rpath problem as you found out too.

comment:23 in reply to:  21 ; Changed 8 years ago by seanfarley (Sean Farley)

Even then, some of the demos are broken, because they expect plugins to be installed in /opt/local/lib. For example, this is what happens for me:

/opt/local/share/cgal/demo/Surface_reconstruction_points_3/Point_set_demo
dyld: Library not loaded: /opt/local/lib/libPS_demo_scene_item.dylib
  Referenced from: /opt/local/share/cgal/demo/Surface_reconstruction_points_3/Point_set_demo
  Reason: image not found
Trace/BPT trap: 5

Patching the CMakeLists file is probably the right way to go, but that's a pain. You can probably fix the programs without plugins using the attached patch for CGAL_CreateSingleSourceCGALProgram.cmake (untested). Perhaps the demos with plugins can be disabled?

Wait a minute. Why make more work for ourselves with this 'demo' variant? Why not create a new port called cgal-examples? This new port would depend on cgal and would avoid all these wonky rpath issues since cgal's examples and demos are actually written expecting cgal to be already installed. Thoughts?

comment:24 in reply to:  22 Changed 8 years ago by mamoll (Mark Moll)

Replying to sean.michael.farley@…:

Replying to mmoll@…:

I need to change the compiler to this: configure.compiler llvm-gcc-4.2 with raphael's patch to comple the demos variant.

I wonder why you need to change the compiler? Is it the way you compiled qt4? For me, raphael's patch compiled but still has the rpath problem as you found out too.

I guess my g++-4.2 is only a left-over stub since I upgraded from snow leopard to lion:

> g++-4.2
g++-4.2: error trying to exec '/usr/bin/i686-apple-darwin11-g++-4.2.1': execvp: No such file or directory

comment:25 in reply to:  23 ; Changed 8 years ago by mamoll (Mark Moll)

Replying to sean.michael.farley@…:

Wait a minute. Why make more work for ourselves with this 'demo' variant? Why not create a new port called cgal-examples? This new port would depend on cgal and would avoid all these wonky rpath issues since cgal's examples and demos are actually written expecting cgal to be already installed. Thoughts?

This still would require patching the CMakeLists.txt files to actually install the demos.

comment:26 in reply to:  25 Changed 8 years ago by seanfarley (Sean Farley)

Replying to mmoll@…:

This still would require patching the CMakeLists.txt files to actually install the demos.

Hmm, yes. I see that some of the demos are sloppy.

comment:27 in reply to:  21 Changed 8 years ago by raphael-st (Raphael Straub)

Replying to mmoll@…:

I need to change the compiler to this: configure.compiler llvm-gcc-4.2

Yes, we don't need to use gcc-4.2 anymore because the demos now compile with llvm-gcc-4.2.

Even then, some of the demos are broken, because they expect plugins to be installed in /opt/local/lib.

This affects only three demos: Mesh_3, Polyhedron and Surface_reconstruction_points_3. I worked around this problem by moving the dynamic libraries of these demos to ${destroot}${prefix}/lib:

eval move [glob ${destroot}${prefix}/share/${name}/demo/*/*.dylib] ${destroot}${prefix}/lib/

Now, even these demos work for me. An updated patch is attached.

Changed 8 years ago by raphael-st (Raphael Straub)

Attachment: Portfile.diff added

comment:28 Changed 8 years ago by mamoll (Mark Moll)

The last Portfile.diff from raphael works for me on 10.7 / Xcode 4.3. My only suggestion is to delete the CMake build cruft that gets installed by adding these lines to post-destroot:

eval delete file [glob  ${destroot}${prefix}/share/${name}/demo/*/CMakeFiles]
eval delete file [glob  ${destroot}${prefix}/share/${name}/examples/*/CMakeFiles]

comment:29 in reply to:  28 Changed 8 years ago by seanfarley (Sean Farley)

Replying to mmoll@…:

The last Portfile.diff from raphael works for me on 10.7 / Xcode 4.3. My only suggestion is to delete the CMake build cruft that gets installed by adding these lines to post-destroot:

eval delete file [glob  ${destroot}${prefix}/share/${name}/demo/*/CMakeFiles]
eval delete file [glob  ${destroot}${prefix}/share/${name}/examples/*/CMakeFiles]

I don't have time to test this patch until tonight but this all seems good to me.

comment:30 Changed 8 years ago by Veence (Vincent)

Okay, fine. If everybody agree, I’ll commit the new Portfile tomorrow. Thanks for the hard work.

comment:31 in reply to:  28 Changed 8 years ago by seanfarley (Sean Farley)

Replying to mmoll@…:

The last Portfile.diff from raphael works for me on 10.7 / Xcode 4.3.

I just wanted to say I was able to build this successfully as well.

comment:32 Changed 8 years ago by Veence (Vincent)

Committed in r91306. Please test and tell me if it’s okay (I’ve a problem with curl that interferes with my own build, and I’m going to bed right now!). Thanks again for working on this update.

comment:33 in reply to:  32 Changed 8 years ago by raphael-st (Raphael Straub)

Replying to vince@…:

Please test and tell me if it’s okay

Yes, it is OK. But I would remove all CMakeFiles directories in the demos variant like mmoll already suggested. A patch is attached.

You can also delete trunk/dports/gis/cgal/files/patch-src-config.h.diff and close #32861.

Changed 8 years ago by raphael-st (Raphael Straub)

Attachment: Portfile_1.diff added

comment:34 Changed 8 years ago by Veence (Vincent)

Resolution: fixed
Status: newclosed

Done. I close the ticket, please reopen it if something goes wrong.

comment:35 Changed 8 years ago by Veence (Vincent)

Oops. r91314

Note: See TracTickets for help on using tickets.