Re: [oce-dev] oce for MacPorts

[D. Barbier]

On 2013/5/16 Greg Allen wrote:
> I've been working on a MacPorts port for oce. You can see the current
> version on bitbucket:
> https://bitbucket.org/gallen/macports-occ/src/default/devel/oce/Portfile
>
> It successfully builds and installs oce and dependencies. I was curious for
> some input at this stage, while I move on to other dependencies of
> python-occ.
>
> Here are a few topics in no particular order:
> - most of the non-tagged ports in MacPorts use datestamps, so I did too
> [lines 8,19,21]
> - Why OCE_INSTALL_PREFIX instead of the usual CMAKE_INSTALL_PREFIX? [line
> 27]

Hi Greg,

I agree that we should use CMAKE_INSTALL_PREFIX.

> - I also added some variants (test and draw), but they both have issues
> [lines 29-36]
> - installing OCE.framework in ${prefix} is a little unusual;
> I moved it to ${prefix}/Library/Frameworks per MacPorts convention [lines
> 38-41]

Yes, feel free to fix this. I could not find detailed explanations on
how to build/install Mac frameworks with CMake.

> I'm having trouble with both variants. Are those of any use, or should I get
> rid of them?

Tests are useful for us. IMO it may be useful for you too, other
people will use your file with different compilers, and these tests
may catch errors.
If you are only interested by pythonocc, you can skip Draw. It is
useful though, there are lots of scripts on OCC forum.

> I've been able to demonstrate passing tests (except 29&30)

What are these failures?

> by installing then testing:
> port install oce
> port -v test oce +test

Normally one can run tests before installation.

> Draw won't install because DRAWEXE depends on a shared library that doesn't
> get installed (TKDraw?):
> port install oce +draw # fails

Libraries which are used only by DRAWEXE have been put into a private
directory to avoid name clashes with system libraries.
On Linux, those libraries are found thanks to RPATH. We discussed
this issue for OSX, I do not remember if this is supposed to work or
if you have to set DYLD_LIBRARY_PATH environment variable.
BTW if you pass -DOCE_INSTALL_PACKAGE_LIB_DIR=lib to cmake, all
libraries will be installed at the same place.

Denis

[Luca Heltai]

I have seen the same error on tcl. I went through the CMakeCache.txt file and made sure that each instance of tkl and wish libraries pointed to mac ports ones. 

OCE seems to ignore the values you give to tk and wish executables and always uses the "wish" which finds first in the path. Pointing all libraries in CMakeCache to macports made it work for me since these are the ones which are on the path first. 

Luca

On 04/giu/2013, at 01:08, Greg Allen <gal...@arlut.utexas.edu> wrote:

On Monday, May 27, 2013 4:01:15 PM UTC-5, Denis Barbier wrote:

> I'm having trouble with both variants. Are those of any use, or should I get
> rid of them?

Tests are useful for us.  IMO it may be useful for you too, other
people will use your file with different compilers, and these tests
may catch errors.
If you are only interested by pythonocc, you can skip Draw.  It is
useful though, there are lots of scripts on OCC forum.

> I've been able to demonstrate passing tests (except 29&30)

What are these failures?

Agreed, so I'm trying to include +test and +draw. If I clone and build (with or without MacPorts), I get:

cmake -DOCE_INSTALL_PREFIX:PATH=/opt/stow-packages/oce -DCMAKE_INSTALL_PREFIX=/opt/stow-packages/oce -DOCE_TESTING:BOOL=ON ..

make

make test

96% tests passed, 2 tests failed out of 47

The following tests FAILED:

29 - OCAFExportTestSuite.testExportAscii (Failed)

30 - OCAFExportTestSuite.testExportNonAscii (Failed)

DRAW won't build:

cmake -DCMAKE_INSTALL_PREFIX=/opt/stow-packages/oce -DOCE_INSTALL_PREFIX:PATH=/opt/stow-packages/oce -DOCE_DRAW:BOOL=ON ..

make

In file included from /Users/allen/Desktop/oce/src/ViewerTest/ViewerTest_ViewerCommands.cxx:88:

/System/Library/Frameworks/Tk.framework/Headers/tk.h:23:3: error: Tk 8.5 must be

      compiled with tcl.h from Tcl 8.5

#       error Tk 8.5 must be compiled with tcl.h from Tcl 8.5

        ^

1 error generated.

Is anyone besides me trying to build with these options on MacOSX?

if you have to set DYLD_LIBRARY_PATH environment variable.
BTW if you pass -DOCE_INSTALL_PACKAGE_LIB_DIR=lib to cmake

I think MacPorts takes care of DYLD. What I remember seeing was that some needed libraries weren't getting installed.

Thanks,

-Greg

--
You received this message because you are subscribed to the Google Groups "oce-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to oce-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jelle feringa]

I recall being bitten by the Tcl.h include issue.

Here's a screencap with the cmake settings that resolved the issue.

The conflict was that the path's linking to TCL /TK were mixed up between the ones that macports supplies and those of the OSX distribution.

Greg, sorry not having respond to this thread earlier, I'm very thrilled to see support for OCE in macports coming about!

-jelle

[D. Barbier]

On 2013/6/4 Greg Allen wrote:
[...]

> 96% tests passed, 2 tests failed out of 47
>
> The following tests FAILED:
> 29 - OCAFExportTestSuite.testExportAscii (Failed)
> 30 - OCAFExportTestSuite.testExportNonAscii (Failed)

[...]

Indeed, I can reproduce these failures on Linux too, strange.
I will investigate.

Denis

[D. Barbier]

This is similar to issue #278, test/OCAFExport_test/CMakeLists.txt must contain:
ADD_OCE_TEST(OCAFExport_test "TKCAF;FWOSPlugin;TKCAF")
so that plugins are found.

A similar topic has been discussed in March, but I did not realize
that some libraries are loaded as plugins and not by the linker.

Denis

[D. Barbier]

On 2013/6/4 D. Barbier wrote:
> On 2013/6/4 D. Barbier wrote:
>> On 2013/6/4 Greg Allen wrote:
>> [...]
>>> 96% tests passed, 2 tests failed out of 47
>>>
>>> The following tests FAILED:
>>> 29 - OCAFExportTestSuite.testExportAscii (Failed)
>>> 30 - OCAFExportTestSuite.testExportNonAscii (Failed)
>> [...]
>>
>> Indeed, I can reproduce these failures on Linux too, strange.
>> I will investigate.
>
> This is similar to issue #278, test/OCAFExport_test/CMakeLists.txt must contain:
> ADD_OCE_TEST(OCAFExport_test "TKCAF;FWOSPlugin;TKCAF")
> so that plugins are found.

Sorry there is a typo, I meant TKCAF;FWOSPlugin;TKBin
See https://github.com/tpaviot/oce/pull/381

Denis

[Greg Allen]

Thanks for all the help! My portfile now builds and installs a seemingly functional DRAWEXE. Is there something I should do to test it? [I've never used OCC/OCE]. I've pushed the latest out to https://bitbucket.org/gallen/macports-occ

I'll check on +test, too.

Thanks,

-Greg

[D. Barbier]

On 2013/6/8 Greg Allen wrote:
> Thanks for all the help! My portfile now builds and installs a seemingly
> functional DRAWEXE. Is there something I should do to test it? [I've never
> used OCC/OCE]. I've pushed the latest out to
> https://bitbucket.org/gallen/macports-occ
>
> I'll check on +test, too.

Hello,

There used to be tcl samples scripts in src/DrawResources/, but they
have been moved into samples/tcl. Since the whole samples/ directory
in OCCT tarballs is quite large (and hardly useful except on Windows
AFAICT) we did not ship this directory.
I just pushed a branch db/add-samples-tcl to add samples/tcl, you can then type
source samples/tcl/VisualizationDemo.tcl
at DRAWEXE prompt.

The script samples/tcl/DataExchangeDemo.tcl needs a file wing.brep
located under data/occ in OCCT tarballs. This directory is also
skipped in our repository because it is very large. This one file had
been copied into samples/tcl, so that you can run
source DataExchangeDemo.tcl
from the samples/tcl directory.

Denis

[jelle feringa]

What about building / running the unit tests than come with OCE?

That would give you an indication of the success of the build?

( I'm asking, not telling ;) )

-jelle

Denis

[Greg Allen]

Yes, the +test variant is for that. For some reason it only wants to load the shared libraries from where they get installed instead of from where they get built. That means the tests only pass if the oce port is already installed (as opposed to testing *before* installation). Still investigating.

I was looking for a way to see if DRAWEXE works. I'll try the suggestions from Denis.

Thanks,

-Greg

[Greg Allen]

On Saturday, June 8, 2013 3:43:01 AM UTC-5, Denis Barbier wrote:

I just pushed a branch db/add-samples-tcl to add samples/tcl, you can then type
  source samples/tcl/VisualizationDemo.tcl
at DRAWEXE prompt.

  source DataExchangeDemo.tcl

I can get both demos to work, with a little duct tape.

I have to run DRAWEXE in ${prefix}/lib for it to find the dylibs it needs. I assume I can set DYLD_LIBRARY_PATH to make it work from elsewhere, but that's breaking the loading of things in /System/Library/Frameworks. I'm still working on this one.

I had to fix the path to wing.brep in DataExchangeDemo.tcl, and then it worked.

When VisualizationDemo.tcl does "vinit", I get an exception:

An exception was caught 0x10d02ad1c : Aspect_DriverDefinitionError: dlopen(/opt/macports-dev/lib/libTKOpenGl.dylib.7, 1): image not found

** Exception ** 0x10d02ad1c : Aspect_DriverDefinitionError: dlopen(/opt/macports-dev/lib/libTKOpenGl.dylib.7, 1): image not found

There is a libTKOpenGl.7.dylib, and if I create a symlink then VisualizationDemo.tcl works

So a few questions:

  - do you see these (small) samples as something that would eventually be included, built, and installed?

    (if so, I can make sure the paths work after being installed)

  - Any ideas where to hunt on dlopen of libTKOpenGl.dylib.7 instead of libTKOpenGl.7.dylib?

I pushed the latest macport (against master) out to https://bitbucket.org/gallen/macports-occ

[Thomas Paviot]

2013/9/19 Greg Allen <gal...@arlut.utexas.edu>

Dear Greg,

I confirm the issues you report. I hope that the coming support of RPATH in the next cmake release will solve the first one. For the second one, you're right, and I used the same tweak. To be honest, I did not pay much attention to this issue since I use to launch DRAWEXE only once per oce release, to test that everything is ok, that is to say not more than three or four times a year.

Regards,

Thomas

 

[D. Barbier]

On 2013/9/19 Thomas Paviot wrote:
> 2013/9/19 Greg Allen wrote:
[...]

>> I have to run DRAWEXE in ${prefix}/lib for it to find the dylibs it needs.
>> I assume I can set DYLD_LIBRARY_PATH to make it work from elsewhere, but
>> that's breaking the loading of things in /System/Library/Frameworks. I'm
>> still working on this one.
>>
>> I had to fix the path to wing.brep in DataExchangeDemo.tcl, and then it
>> worked.
>>
>> When VisualizationDemo.tcl does "vinit", I get an exception:
>> An exception was caught 0x10d02ad1c : Aspect_DriverDefinitionError:
>> dlopen(/opt/macports-dev/lib/libTKOpenGl.dylib.7, 1): image not found
>> ** Exception ** 0x10d02ad1c : Aspect_DriverDefinitionError:
>> dlopen(/opt/macports-dev/lib/libTKOpenGl.dylib.7, 1): image not found
>>
>> There is a libTKOpenGl.7.dylib, and if I create a symlink then
>> VisualizationDemo.tcl works
>>
>> So a few questions:
>> - do you see these (small) samples as something that would eventually be
>> included, built, and installed?
>> (if so, I can make sure the paths work after being installed)
>> - Any ideas where to hunt on dlopen of libTKOpenGl.dylib.7 instead of
>> libTKOpenGl.7.dylib?
>>
>> I pushed the latest macport (against master) out to
>> https://bitbucket.org/gallen/macports-occ
>>
>
> Dear Greg,
>
> I confirm the issues you report. I hope that the coming support of RPATH in
> the next cmake release will solve the first one.

Hello,

For the record, Thomas is talking here about this thread:
https://groups.google.com/d/msg/oce-dev/P3lCwtl2nig/zN6A1r-2Ku4J

This discussion about samples got out of my mind; yes, I do believe
that we should ship them, but there is no hurry, we can work on this
issue after OCE 0.13 is out.

> For the second one, you're
> right, and I used the same tweak. To be honest, I did not pay much attention
> to this issue since I use to launch DRAWEXE only once per oce release, to
> test that everything is ok, that is to say not more than three or four times
> a year.

This path is set at l. 1000 of top-level CMakeLists.txt:
set(OCE_DEFAULT_CSF_GraphicShr
${OCE_DEFAULT_CSF_GraphicShr}.${OCE_ABI_SOVERSION})

Denis

[Greg Allen]

>> There is a libTKOpenGl.7.dylib, and if I create a symlink then VisualizationDemo.tcl works

I pushed a fix for this to my github

  https://github.com/GregoryEAllen/oce

I'm not sure if I should have made a branch or pull request for this small change.

Works on MacOS, should be identical on everything else (but don't have a setup to test).

 

> I confirm the issues you report. I hope that the coming support of RPATH...

I think that also explains why my +test variant fails unless oce is already installed. This also renders DRAWEXE fairly useless.

>This discussion about samples got out of my mind;

Me, too. The last two months of my free time were consumed by a large home improvement project. :)

Thanks,

-Greg

[Rajeev Jain]

Are there plans for homebrew?

Rajeev

[D. Barbier]

On 2013/9/27 Greg Allen wrote:
>> >> There is a libTKOpenGl.7.dylib, and if I create a symlink then
>> >> VisualizationDemo.tcl works
>
> I pushed a fix for this to my github
> https://github.com/GregoryEAllen/oce
> I'm not sure if I should have made a branch or pull request for this small
> change.

Hello,

Ideally, you create a branch in our repository and perform a pull
request; we can then edit it if changes are needed, or rebase it for
instance.
Your change looks good, but I had to review it for several minutes in
order to check that everything is right in all cases. IMO this
(untested, please carefully check, and sorry for poor formatting)
construct is more readable:

set(OCE_DEFAULT_CSF_GraphicShr
${OCE_INSTALL_PREFIX}/${OCE_INSTALL_LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}TKOpenGl)
if (OCE_NO_LIBRARY_VERSION)
set(OCE_DEFAULT_CSF_GraphicShr
${OCE_DEFAULT_CSF_GraphicShr}${CMAKE_SHARED_LIBRARY_SUFFIX})
else (OCE_NO_LIBRARY_VERSION)
if (APPLE)
set(OCE_DEFAULT_CSF_GraphicShr
${OCE_DEFAULT_CSF_GraphicShr}.${OCE_ABI_SOVERSION}${CMAKE_SHARED_LIBRARY_SUFFIX})
else (APPLE)
set(OCE_DEFAULT_CSF_GraphicShr
${OCE_DEFAULT_CSF_GraphicShr}${CMAKE_SHARED_LIBRARY_SUFFIX}.${OCE_ABI_SOVERSION})
endif (APPLE)
endif (OCE_NO_LIBRARY_VERSION)

> Works on MacOS, should be identical on everything else (but don't have a
> setup to test).

[...]

No problem, other porters will tell if this causes trouble.

Denis

[Greg Allen]

On Friday, September 27, 2013 8:28:03 AM UTC-5, Rajeev Jain wrote:

Are there plans for homebrew?

No plans on my part. However, some of my McFixes may help other McUsers regardless of how they install.

Thanks,

-Greg

[Greg Allen]

On Friday, September 27, 2013 9:53:15 AM UTC-5, Denis Barbier wrote:

branch in our repository and perform a pull request

Still working on MacPorts. Now I can run DRAWEXE with the right ENV, and I can also pass ctest with the right (different) ENV.

I've found that setting DYLD_LIBRARY_PATH will break everything, but setting DYLD_FALLBACK_LIBRARY_PATH to ${prefix}/lib will allow DRAWEXE to work fine.

ctest is more complicated. Because the libraries are scattered about in the build directory, the path I have to add is ${build}/adm/cmake/*/Darwin/i386 or some such. It's certainly possible, but it's very long and messy.

An alternative is to put all the libraries in the same build location, say ${build}/adm/cmake/lib

That could easily be done with (in adm/cmake/BuildToolkit.cmake):

set_target_properties(${TOOLKIT} PROPERTIES

    LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/../lib

)

Then the ENV for ctest is simply 

DYLD_FALLBACK_LIBRARY_PATH=${build}/adm/cmake/lib

and I get:

$ port -vd test oce +test

   ... <wait a very long time> ...

100% tests passed, 0 tests failed out of 47

Thoughts?

cmake-2.8.12 is out and I'm using it. Was there some Mac change that needed to be made as a consequence?

Thanks,

-Greg

[D. Barbier]

On 2013/10/24 Greg Allen wrote:
> On Friday, September 27, 2013 9:53:15 AM UTC-5, Denis Barbier wrote:
>>
>> branch in our repository and perform a pull request
>
>
> Still working on MacPorts. Now I can run DRAWEXE with the right ENV, and I
> can also pass ctest with the right (different) ENV.

Hello,

Great news.

> I've found that setting DYLD_LIBRARY_PATH will break everything, but setting
> DYLD_FALLBACK_LIBRARY_PATH to ${prefix}/lib will allow DRAWEXE to work fine.

If setting DYLD_LIBRARY_PATH breaks everything, this means that you
have libraries in ${prefix}/lib which are used by other applications.
These are not OCE libraries, but others. Maybe you should remove
those libraries?
As mentioned in another thread,

> ctest is more complicated. Because the libraries are scattered about in the
> build directory, the path I have to add is ${build}/adm/cmake/*/Darwin/i386
> or some such. It's certainly possible, but it's very long and messy.
>
> An alternative is to put all the libraries in the same build location, say
> ${build}/adm/cmake/lib
>
> That could easily be done with (in adm/cmake/BuildToolkit.cmake):
> set_target_properties(${TOOLKIT} PROPERTIES
> LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/../lib
> )
>
> Then the ENV for ctest is simply
> DYLD_FALLBACK_LIBRARY_PATH=${build}/adm/cmake/lib
>
> and I get:
> $ port -vd test oce +test
> ... <wait a very long time> ...
> 100% tests passed, 0 tests failed out of 47
>
> Thoughts?

I am facing similar issues on Linux when running OCCT tests, because
some shared libraries are loaded at runtime and thus do not rely on
RPATH. I decided to copy libraries in adm/cmake/DRAWEXE/, see my
db/fixup-OCCT-tests branch. Your solution is simpler, but it requires
more work:
* Output directory must depend on configuration (Debug, Release, etc)
so that one can build both Debug and Release without trouble.
* When building OCE as part of a larger project, people may set
CMAKE_LIBRARY_OUTPUT_DIRECTORY to gather all their libs into a single
location. Setting LIBRARY_OUTPUT_DIRECTORY property breaks those
builds, see issue #358.

> cmake-2.8.12 is out and I'm using it. Was there some Mac change that needed
> to be made as a consequence?

I do not understand your question.
Release notes for 2.8.12 contain those items:
- Introduced: Support for RPATH under OSX
- Please see the blog post by Clinton Stimpson about using RPATH on OSX
(http://www.kitware.com/blog/home/post/510)

It would be great to use this RPATH support when available in our
CMakeLists.txt.

Denis