Comments (35)
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
from simbody.
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.
from simbody.
Tests are passing. Aside from the pkgconfig file (#68) it looks ready to release.
@j-rivero Is #68 a priority right now?
from simbody.
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?
from simbody.
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
from simbody.
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?
from simbody.
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.
from simbody.
Oh, I see -- thanks. So CMAKE_INSTALL_PREFIX
is currently /usr for Debian, so I could set it to /usr/sherm or whatever?
from simbody.
You could install to /usr/sherm
or to your home folder $HOME/local
(which is where I often install things).
from simbody.
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.
from simbody.
I think @j-rivero and I are ready when you are.
from simbody.
Indeed.
from simbody.
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
from simbody.
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?
from simbody.
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.
from simbody.
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.
from simbody.
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 [email protected]:
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
.
from simbody.
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).
from simbody.
I'm volunteer for the extra credit version if running it from our jenkins is a valid option for you.
from simbody.
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.)
from simbody.
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.
from simbody.
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.
from simbody.
I just tested on Ubuntu and it works now. I had also previously tested with homebrew and it works there too.
from simbody.
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
from simbody.
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?
from simbody.
On Ubuntu I did the following:
- Install Simbody master using cmake and
make install
, withCMAKE_INSTALL_PREFIX=/usr
. - 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.
from simbody.
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
.
from simbody.
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.
from simbody.
@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.
from simbody.
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 :)
from simbody.
@sherm1 Where does this stand? Has OpenSim been patched?
from simbody.
OpenSim has been patched.
On Wed, Feb 26, 2014 at 10:15 AM, Steven Peters [email protected]:
@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
.
from simbody.
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.
from simbody.
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.
from simbody.
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.
from simbody.
Related Issues (20)
- Usage of SimTK::Vec for custom types. HOT 1
- Incoming PR - Improvement to ExponentialSpringForce HOT 4
- The OBJ file parser should ignore all kinds of whitespace for face (`f`) commands HOT 2
- TestBigMatrix fails on mips64el and ppc64el architectures HOT 8
- Rack Pinion Mobilizer HOT 3
- Problem when weighting integration accuracy
- TestCustomConstraints (Failed) on x86_64
- Setting output precision for String::String(const T& t) HOT 4
- "No such file or directory" HOT 6
- Visualizer crashes when drive letters don't match HOT 6
- Cannot compile in C++20 if a compilation unit uses `MultibodyGraphMaker.h`
- `getContiguousScalarData` has different behavior for `RowVector` and `RowVectorView` HOT 3
- Variable precision for String::String(const T& t) and Xml::setValueAs(const T& t) HOT 3
- Simbody Visualization not working on MacOS HOT 1
- Specifying XML output precision with an optional argument causes a bug for variables of type bool HOT 1
- TestXML fails on Windows 11, Visual Studio 2022 with a Release build. HOT 2
- Expose `SimbodyMatterSubsystemRep::multiplyByPVATranspose` to `SimbodyMatterSubsystem` HOT 2
- Visaulization HOT 1
- Simbody core aborted while using it with gazebo classic after loading a SDF. HOT 6
- Efficiently calculating a subset of a system's body and mobility forces HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from simbody.