Plan for a new simbody release (3.4)?

[j-rivero]

Dear Simbody team:

Is there any plan to release a new version of simbody? I was looking to ask debian for an official submission but it would be great to release an official version with all the latest changes we did to the build system and examples.

Thanks.

P.D: my best wishes for this new year and thanks for all the collaboration you have done during the 2013 :)

[sherm1]

Thanks, José! A 3.4 release with the new build system seems like a good idea. I want to wait to hear from @scpeters (next week?) because I think there are still a few loose ends to deal with.

Best regards and happy New Year,
Sherm

[scpeters]

I think it would be good to make a new release. One outstanding issue that may be easy to resolve is #68 (provide a pkgconfig file), but that's probably not a deal-breaker.

I would also like to make sure the gazebo tests still pass with the simbody master branch.

[scpeters]

Tests are passing. Aside from the pkgconfig file (#68) it looks ready to release.

@j-rivero Is #68 a priority right now?

[sherm1]

Steve, I think last time we looked at this together there was a problem with the include files going directly into /usr/include/.h rather than /usr/include/simbody/.h. Did you fix that already?

[scpeters]

We talked about it, but I think I was waiting for you to create an issue about it. So I haven't done anything yet.

EDIT: I just created #101

[sherm1]

OK, thanks Steve. Before we close this and make a new release I'd like to make sure the following cases all work (still):

• On Windows, build the INSTALL target in Visual Studio
• On Mac, build and then "make install" (goes into /usr/local/simbody)
• On Linux (not necessarily Debian), build then "make install"; can follow GNUInstallDirs
• Install using the debian package on Ubuntu [which releases?]
• Install using Steve's homebrew recipe
• Anything else? pkgconfig?

I can test the first three but don't know how to test the other ones.

One thing I'm unclear about regarding the Linux changes is how users without root access can install Simbody. We currently have users that install on Linux clusters they don't own. Previous releases installed everything under a common SIMBODY_HOME directory (default "/usr/local/simbody" but easily changed) so non-root installation is ok. Is that still possible using GNUInstallDirs?

[scpeters]

The home-brew recipe can be tested with the following:

# install homebrew
brew update
brew tap osrf/simulation
# install simbody master branch (HEAD)
brew install simbody --HEAD

If you don't have root access, you should be able to specify the CMAKE_INSTALL_PREFIX variable to change the install location to a local folder, though the LD_LIBRARY_PATH environment variable will have to be updated.

[sherm1]

Oh, I see -- thanks. So CMAKE_INSTALL_PREFIX is currently /usr for Debian, so I could set it to /usr/sherm or whatever?

[scpeters]

You could install to /usr/sherm or to your home folder $HOME/local (which is where I often install things).

[j-rivero]

Thanks @sherm1, @scpeters . I will finish the work on #68 , it's nice to provide debian/ubuntu users with a pkgconfig files for all the people out there not using cmake and sound like a good thing to me to have from the beginning of the debian inclusion.

Package generation and installation will be tested in both Ubuntu (we probably want to generate new packages for the OSRF repository) and for Debian (I will do it before request the inclusion and the person who performs the upload will do the same).

For the homebrew, I added to my TODO list to incorporate a continuous integration job, so we can be sure that changes are not braking simbody on Mac. I will let you know as soon as I have it configured.

[scpeters]

I think @j-rivero and I are ready when you are.

[j-rivero]

Indeed.

[sherm1]

Yikes – while testing this I just discovered that Simbody’s installation was completely broken (on every platform!) by a change made a few weeks ago in PR #102. Does this mean that no one has tried to use an installed version of Simbody since then? Or am I misunderstanding something?

At the moment I’m very skeptical that this is ready to go.

Sherm

[scpeters]

I apparently hadn't been testing on a sufficiently isolated machine. I had a local install of the latest simbody changes, but there was also a system install of 3.3, which was providing the simmath include files.

Sorry I botched this. Perhaps we should add a post-install test to travis to verify building 3rd-party libraries?

[chrisdembia]

I tried a few weeks ago (when making the readme) to run examples, and was not able to get the examples to pick up simbody-visualizer. I just assumed that I was doing something wrong though. Ubuntu 13.10.

[sherm1]

An automated post-install test on Travis would be awesome. Not sure I know how to do that, though. Hopefully we won't be changing the installation procedure very often, so I am OK with manual testing. But I see that is a little tricky! Anyway, I'm just finishing with some tests and then I'll commit some fixes. Once we split off the 3.4 branch I would like to see a final round of tests on all three platforms just to be sure it is working.

[chrisdembia]

It looks like travis can test on OS X
http://docs.travis-ci.com/user/osx-ci-environment/

EDIT: maybe not quite yet: travis-ci/travis-ci#216

On Mon, Feb 3, 2014 at 2:37 PM, Michael Sherman notifications@github.comwrote:

An automated post-install test on Travis would be awesome. Not sure I know
how to do that, though. Hopefully we won't be changing the installation
procedure very often, so I am OK with manual testing. But I see that is a
little tricky! Anyway, I'm just finishing with some tests and then I'll
commit some fixes. Once we split off the 3.4 branch I would like to see a
final round of tests on all three platforms just to be sure it is working.

Reply to this email directly or view it on GitHubhttps://github.com//issues/96#issuecomment-34009199
.

[sherm1]

OSX and Windows support would be great. In the meanwhile, adding an automated post-install test per Steve's suggestion would be a nice addition. The basic test would be: make install, followed by compile and build of a test program (like the PendulumNoViz installation test) using the installed software. The extra credit version would be one that verifies that it can run the visualizer (I think we would need a way to run the visualizer in no-graphics mode; the test would be whether the executable was successfully located and run).

[j-rivero]

I'm volunteer for the extra credit version if running it from our jenkins is a valid option for you.

[sherm1]

Thanks, Jose! I'm not sure I understand what you mean though -- if the test is in the Simbody repo wouldn't Travis also pick it up? Also, I don't think Gazebo uses the Simbody visualizer at all -- does it get built? (Now that I think of it I think @chrisdembia may have intentionally left the visualizer out of the Travis build also to avoid tricky dependencies.)

[j-rivero]

Let me explain it a bit better:

Travis is really cool to run tests and integrate the results in bitbucket. As far as it fists your needs, it is the best option. However, I'm not sure about running graphical apps. At the OSRF we use our jenkins nodes to run graphical tests, so for sure it could be used to perform the kind of test that runs the visualizer.

This has nothing to do with gazebo using the visualizer.

[sherm1]

Thanks -- I see. I think we don't actually need to run any graphics -- just test whether the visualizer can be found and executed after the installation. That might work on Travis too.

My thought about gazebo & the visualizer was just that the gazebo build of its simbody dependency probably does not currently include the visualizer, which is an optional part of the simbody build. The same is currently true for our Travis build, I believe.

[scpeters]

I just tested on Ubuntu and it works now. I had also previously tested with homebrew and it works there too.

[sherm1]

An OpenSim user just sent me an email. She was confused by the new installation on Mac and couldn't get OpenSim to build anymore. Sigh. I guess this emphasizes that we'll need to document this well at least. An alternative would be to provide a backwards-compatible option for installing in the "old style" /usr/local/simbody/* structure for Mac and Linux.

Hi Sherm,

I was trying to build/install the simbody source code on my Mac.. and the build works just fine, 
but for whatever reason, the "install" part isn't working the way it used to with an older version 
of the source code (the last time I updated was back in September..).  In my old install 
folder, I used to have a bin, doc, examples, include, lib, libexec, and share folder.  Now, 
however, after I install, I only get the include, lib, libexec, and share folders.  It particularly 
becomes an issue because I think OpenSim is specifically looking for some of the missing 
folders..

I think it has something to do with some setting I may need to change when building on my 
Mac (I asked Carmichael who's building in VisualStudio and it wasn't an issue for him).  I 
tried building/installing in Xcode and just using unix makefiles, and both had the same 
install directory issue.  Do you have idea of what may be causing this?  Or can I bring my 
laptop down to show you later today?  Sorry to bug you with this so often!

Thanks,
Apoorva

[chrisdembia]

I think this just means OpenSim needs to be updated to search for Simbody properly, by looking for the FindSimbody.cmake that we now generate. Instead of OpenSim assuming it knows the structure of Simbody, it should do a find_package(Simbody), right?

[chrisdembia]

On Ubuntu I did the following:

1. Install Simbody master using cmake and make install, with CMAKE_INSTALL_PREFIX=/usr.
2. In OpenSim, delete the FindSimbody.cmake file, then just ran cmake and make. It found Simbody! Because in step 1, I gave CMake a way to find SimbodyConfig.cmake.

The issue arises if I don't want to install Simbody to /usr. In that case, maybe we need to find a way to use OpenSim's SimTK_INSTALL_DIR to find that Config.cmake file. Alternatively, see http://stackoverflow.com/questions/14230565/how-to-make-cmake-find-a-package-configuration-file. I don't think we could expect users to locate the SimbodyConfig.cmake file on their own...so maybe Sherm is right about allowing an old style install.

[j-rivero]

I'm don't understand the exact problem described by the user and personally I've never used Xcode.

If we speak about linux cmake installations, the point, as I understand it, it is easy:

• If you use standard paths used by find_package to make your installation, such as /usr in CMAKE_INSTALL_PREFIX, all should work out of the box.
• If you use non standard paths to make your installation, then the same user is responsible to use CMAKE_PREFIX_PATH to make cmake know about your module.

I would like to assume that things in Mac should work in the same way, with cmake translating the paths to MacOsX standards transparently, if we are doing it right.

I'm not sure about what you mean by old style installation.

[sherm1]

Thanks, Chris -- this sounds like a reasonable fix for OpenSim, which can certainly learn to find SimbodyConfig.cmake. Individual users I'm less worried about. There is already a sample CMakeLists file they can use (optionally) or we can just give them some instructions. In the long run it will be less trouble I think if there is just one install procedure.

If you want to make that change to OpenSim trunk I think it is a good idea but you should probably check with Ayman just to make sure, and let everyone know because they will have to switch to Simbody 3.4 (master) if they aren't already using it.

[chrisdembia]

@j-rivero , the default value of CMAKE_INSTALL_PREFIX on my machine is /usr/local, so the user would need to alter the default behavior (change to /usr) to get it to work "out of the box". So I'd say this doesn't work out of the box.

For a non-standard install, setting CMAKE_PREFIX_PATH to a non-standard directory worked perfectly 😄.

When simbody is installed non-standardly, I get this error:

CMake Error at CMakeLists.txt:292 (find_package):
  By not providing "FindSimbody.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Simbody", but
  CMake did not find one.

  Could not find a package configuration file provided by "Simbody" with any
  of the following names:

    SimbodyConfig.cmake
    simbody-config.cmake

  Add the installation prefix of "Simbody" to CMAKE_PREFIX_PATH or set
  "Simbody_DIR" to a directory containing one of the above files.  If
  "Simbody" provides a separate development package or SDK, be sure it has
  been installed.

The error tells the user to set CMAKE_PREFIX_PATH, but I think we should help them out more than this, with something like (psuedocode)

if ENV{SimTK_INSTALL_DIR}, append(CMAKE_PREFIX_PATH "ENV{SimTK_INSTALL_DIR}")

In any case, I won't make these changes to OpenSim until Simbody 3.4 is actually released. But hopefully I'll add a Version.cmake file to Simbody before the 3.4 release.

[j-rivero]

I mostly agree, Chris. The point of cmake using the default to /usr/local comes from the LHS and standard paths to place the software installed locally.

Some measures could be taken to help users, but for an out-of-the-box deployment, one should point to proper packages. Manually compiling things requires of some skills, which could include reading an INSTALL file and understand the default cmake behaviour :)

[scpeters]

@sherm1 Where does this stand? Has OpenSim been patched?

[chrisdembia]

OpenSim has been patched.

On Wed, Feb 26, 2014 at 10:15 AM, Steven Peters notifications@github.comwrote:

@sherm1 https://github.com/sherm1 Where does this stand? Has OpenSim
been patched?

Reply to this email directly or view it on GitHubhttps://github.com//issues/96#issuecomment-36157168
.

[sherm1]

I split off a 3.4 branch but it's not ready yet to be tagged as a release. I won't have any time to work on it until the contact code is operational in the master branch.

[scpeters]

Just a heads up that there is at least one user outside OSRF looking forward to the release of 3.4, as it has some fixes that are required to build on OSX 10.9.

osrf/homebrew-simulation#10

[sherm1]

Ok, now I feel bad. Apparently it's going to take forever for me to get around to fixing up the install instructions, so I decided to tag it as-is. Simbody 3.4 is now released. We can always make a 3.4.1 release with some sweetened documentation.