On Tue, Nov 22, 2011 at 9:01 AM, Dirk Thomas <mail@dirk-thomas.net> wrote:
>
> I don't see a problem here (but may be I just don't know enough about how
> this new install feature works).
>
> Each package is responsible to find resources located somewhere "inside" the
> own package.
> Therefore it must use a reasonable install destination for all those
> resources so that they are still found.
>
> I.e. the package "rosgui" uses an image which is stored inside the package
> in the relative path "icons/ros_org_vertical.png".
> The "basedir" for loading the image is actually the path of the package as
> returned by ROS.
> If ROS returns "/path/to/packageN/" as the package path the image must be
> installed to "/path/to/packageN/icons/ros_org_vertical.png".
>

I think the relevant details are that:

- There is a strict separation of build products from what gets
checked out of source control; that is, the build and source
directories for packageN will be different.  libpackageN.so and
packageN/somepython.py will exist in completely different places
before installation, and these places will be different when "built"
and after installation.

-  "/path/to/stacks/stackN/packageN" won't exist, per se.  But
/path/to/share/packageN/anything_you_like may exist (if packageN
chooses to install things that way).  The point is that /path/to will
be the CMAKE_INSTALL_PREFIX, and under this prefix things will be
installed in as FHS-ish a scheme as possible.

My instinct says that we should discuss what the contents of
/path/to/share/projectN/ will contain.  The only directory that is
spoken for already is cmake/.

So, something like...

/path/to/share/projectN/
  cmake/
  plugins/
  resources/
  data/

I don't have a good sense of what the specifics should be.

-t