<p dir="ltr">That sounds like a great way to deal with GNUInstallDirs at release time.</p>
<p dir="ltr">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.</p>
<p dir="ltr">- Dirk</p>
<div class="gmail_quote">On Apr 9, 2014 7:34 PM, "William Woodall" <<a href="mailto:william@osrfoundation.org">william@osrfoundation.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">That seems reasonable, I think that variable is usually relative (from a brief search on the internet), so it should simply be `-D<span style="font-family:arial,sans-serif;font-size:13px">CMAKE_INSTALL_LIBDIR=lib`. The `CMAKE_INSTALL_PREFIX` will automatically be put before it.</span><div>


<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">This rule modification should _only_ be used for the `rosdebian` bloom generator and not the plain `debian` generator.</span></div>


</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 7:28 PM, Thomas Moulard <span dir="ltr"><<a href="mailto:thomas.moulard@gmail.com" target="_blank">thomas.moulard@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Apr 10, 2014 at 10:30 AM, William Woodall<br>
<<a href="mailto:william@osrfoundation.org" target="_blank">william@osrfoundation.org</a>> wrote:<br>
> Does that mean it would just be overriding GNUInstallDirs.cmake by<br>
> explicitly setting the libdir? I don't have a problem with that in<br>
> principle, but it is going to be difficult to know if it will cause any<br>
> unintended problems with other packages or not.<br>
<br>
</div>Yes, exactly.<br>
<br>
IMHO this is good practice: the upstream package makes all the<br>
directories configurable<br>
and once you know the platform, you hardcode everything to avoid<br>
relying on guessing.<br>
<br>
Given how popular this macro is and how explicit the name is I doubt<br>
there will be<br>
any name clash. It would also be less intrusive than having all the<br>
package looking for<br>
CATKIN_BUILD_BINARY_PACKAGE and hence introducing Catkin-specific mechanisms<br>
upstream.<br>
<span><font color="#888888"><br>
--<br>
Thomas<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>William Woodall<div>ROS Development Team</div><div><a href="mailto:william@osrfoundation.org" target="_blank">william@osrfoundation.org</a></div>


<div><a href="http://williamjwoodall.com/" target="_blank">http://williamjwoodall.com/</a></div>
</div>
</blockquote></div>