Fix #101, install includes to simbody subfolder

[scpeters]

Install header files to simbody subfolder to prevent mixing
with other system header files. Fixes #101.

[sherm1]

Steve, I think this breaks the Windows installation. There the standard is to install everything under a product directory, so the installation goes into simbody/include rather than include/simbody.

There are really two styles of installation that have to coexist, on various platforms:

• the "everything is under a product directory" style for Windows and some Mac & Linux "/usr/local/simbody"-style installations, and
• the "similar file types go together" like Debian, where some files are mixed directly (/usr/lib/libsimbody.so) and some must still be segregated to avoid conflicts (/usr/share/doc/simbody, /usr/include/simbody)
• are there also complications involving symbolic links on some platforms?

I really don't have a clear picture of how this is supposed to work. For years I have used a dumb approach that worked on every platform -- "make install" would put all the files under a common SIMBODY_HOME directory on Windows, OSX, and Linux; uninstall consisted of deleting that directory. I like the more sophisticated installation scheme, but we need to figure out how to have it peacefully coexist with the other method. Maybe we need to step back and write down the whole multiplatform picture before making more code changes? I'm not sure we're converging. Possibly there is no solution that can be done one platform at a time. Ideas @hsu, @j-rivero ?

[j-rivero]

The rationale behind the Linux multiple destinations comes from Linux FHS (Filesystem Hierarchy Standard).

In some way you can still installing all under a single directory if you use the CMAKE_INSTALL_PREFIX, which could have a default value in some platforms if you think that this helps to your users. I would not recommend it at least for Linux but I don't have experience enough to speak about Mac or Windows, sorry.

Just a reminder that for getting simbody into main Linux distribution, the FHS is a must.

[scpeters]

I just updated the pull request to fix the Win32 installation. @sherm1 can you test it again?

[sherm1]

Will do. Thanks, Steve.

[sherm1]

Looks good on Windows (64 bit).

I noticed that the CMake config file is in lib/cmake/*.config. That seems a little buried but I don't really know where to put it.

[sherm1]

PS I haven't tested this on Mac or Linux.

[scpeters]

I tested it on mac and linux, so I think we're ok in terms of the header file locations.

I just read up on where the cmake config files need to be in the cmake documentation. Apparently, the current location looks to be incorrect for Windows. Here is the list of valid locations for Windows:

<prefix>/                                               (W)
<prefix>/(cmake|CMake)/                                 (W)
<prefix>/<name>*/                                       (W)
<prefix>/<name>*/(cmake|CMake)/                         (W)

and here is the list for Unix:

<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/          (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/                (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/  (U)

I'll make another pull request to fix the cmake config location for Windows. EDIT: #107