[ros-release] Indigo and multiarch support

[Dirk Thomas]

That sounds like a great way to deal with GNUInstallDirs at release time.

I guess we still need a good way to make it work seamlessly when packages
are build by users. May be we can come up with a similar elegant solution
for that.

- Dirk
On Apr 9, 2014 7:34 PM, "William Woodall" <william at osrfoundation.org> wrote:

> That seems reasonable, I think that variable is usually relative (from a
> brief search on the internet), so it should simply be `-DCMAKE_INSTALL_LIBDIR=lib`.
> The `CMAKE_INSTALL_PREFIX` will automatically be put before it.
>
> This rule modification should _only_ be used for the `rosdebian` bloom
> generator and not the plain `debian` generator.
>
>
> On Wed, Apr 9, 2014 at 7:28 PM, Thomas Moulard <thomas.moulard at gmail.com>wrote:
>
>> On Thu, Apr 10, 2014 at 10:30 AM, William Woodall
>> <william at osrfoundation.org> wrote:
>> > Does that mean it would just be overriding GNUInstallDirs.cmake by
>> > explicitly setting the libdir? I don't have a problem with that in
>> > principle, but it is going to be difficult to know if it will cause any
>> > unintended problems with other packages or not.
>>
>> Yes, exactly.
>>
>> IMHO this is good practice: the upstream package makes all the
>> directories configurable
>> and once you know the platform, you hardcode everything to avoid
>> relying on guessing.
>>
>> Given how popular this macro is and how explicit the name is I doubt
>> there will be
>> any name clash. It would also be less intrusive than having all the
>> package looking for
>> CATKIN_BUILD_BINARY_PACKAGE and hence introducing Catkin-specific
>> mechanisms
>> upstream.
>>
>> --
>> Thomas
>>
>
>
>
> --
> William Woodall
> ROS Development Team
> william at osrfoundation.org
> http://williamjwoodall.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20140409/db3f9fe3/attachment.html>