<div><br></div><div>I have thought about doing that - it's not hard to add a bit of extra cmake to get it to build both toolchain and runtime debs/rpms. However, there's a huge number of embedded platforms out there and you'll often want to fully optimise your build flags (-march and -mtune/-mcpu) to get as much speed as possible on your embedded board so my first priority is just to get some cross recipes from source up and working as that provides a convenient way to cover all bases. </div>
<div><br></div><div>If you want to add to the cmake scripts with some packaging code, feel free to send some modifications in, or I can give you direct access. Later I might tackle it myself - even if it's only for personal repos, it would help in development in some instances.<br>
</div><br><div class="gmail_quote">On 10 July 2010 16:36, Cedric Pradalier <span dir="ltr"><<a href="mailto:cedric.pradalier@mavt.ethz.ch">cedric.pradalier@mavt.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello Daniel,<br>
<br>
I'm very glad to hear that you're so advanced on the cross-compilation<br>
question. I am still experimenting and making it work by trial and errors...<br>
Do you thing there would be a chance to setup a package repository with<br>
the built binaries? I'm running a stripped down ubuntu on my gumstix<br>
verdex and overo, and having pre-built packages would be a game changer.<br>
However, for these applications, the deb-packages would have to be<br>
cleaned up to save a bit of space :)<br>
<br>
Best,<br>
<div><div class="h5"><br>
On 07/10/10 06:36, Daniel Stonier wrote:<br>
> There are already some patches submitted to ros trac covering some of<br>
> these things - while they didn't get in in time for cturtle, hopefully<br>
> they'll be in the next release<br>
><br>
> <a href="https://code.ros.org/trac/ros/ticket/2803" target="_blank">https://code.ros.org/trac/ros/ticket/2803</a> - sets up rospack for a twopass<br>
> <a href="https://code.ros.org/trac/ros/ticket/2805" target="_blank">https://code.ros.org/trac/ros/ticket/2805</a> - sets up genmsg_cpp for a twopass<br>
> <a href="https://code.ros.org/trac/ros/ticket/2823" target="_blank">https://code.ros.org/trac/ros/ticket/2823</a> - a fix for a stray test<br>
> that causes a problem in crossing topic_tools<br>
> <a href="https://code.ros.org/trac/ros/ticket/2822" target="_blank">https://code.ros.org/trac/ros/ticket/2822</a> - a fix for a find_file in<br>
> cmake that can't find things in a cross in message_filters<br>
> <a href="https://code.ros.org/trac/ros/ticket/2821" target="_blank">https://code.ros.org/trac/ros/ticket/2821</a> - find_file again causing<br>
> problems in topic_tools<br>
> <a href="https://code.ros.org/trac/ros/ticket/2670" target="_blank">https://code.ros.org/trac/ros/ticket/2670</a> - fix to allow<br>
> rostoolchain.cmake and rosconfig.cmake to exist together<br>
><br>
> Your fix for private.cmake I was sure I submitted a few months ago,<br>
> but I can't find it in the trac system - I maintain exactly the same<br>
> patch myself. I'll check it again a bit later to make sure its there.<br>
> I've also got a cross compiled opencv package for embedded systems<br>
> (minus all the gui components) that does what you're doing and a bit<br>
> more:<br>
><br>
> svn export <a href="http://embedded-control-library.googlecode.com/svn/trunk/ecl_vision/opencv_embedded" target="_blank">http://embedded-control-library.googlecode.com/svn/trunk/ecl_vision/opencv_embedded</a><br>
> ./opencv<br>
><br>
> On 9 July 2010 21:55, Cedric Pradalier<<a href="mailto:cedric.pradalier@mavt.ethz.ch">cedric.pradalier@mavt.ethz.ch</a>>  wrote:<br>
><br>
>> Hi,<br>
>><br>
>> I'd like to suggest the 2 micro-patch to help cross-compiling ros.<br>
>><br>
>> ======== ROS BUILD ========<br>
>> I now use more the rostoolchain.cmake and I really think that's the way<br>
>> forward. Mine looks like that:<br>
>> set(CMAKE_SYSTEM_NAME Linux)<br>
>> set(CMAKE_SYSTEM_PROCESSOR arm-angstrom-linux-gnueabi)<br>
>> set(GUMSTIXTOP [...]/overo-oe)<br>
>> set(GUMSTIXFS [...]/overo-dev)<br>
>> set(CMAKE_C_COMPILER<br>
>><br>
>> ${GUMSTIXTOP}/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-gcc-sysroot)<br>
>> set(CMAKE_CXX_COMPILER<br>
>><br>
>> ${GUMSTIXTOP}/tmp/cross/armv7a/bin/arm-angstrom-linux-gnueabi-g++-sysroot)<br>
>> set(CMAKE_FIND_ROOT_PATH ${GUMSTIXFS})<br>
>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)<br>
>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)<br>
>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)<br>
>><br>
>> The CMAKE_FIND... directives are conflicting with the<br>
>> _rosbuild_add_rostest and _rosbuild_add_pyunit in<br>
>> rosbuild/private.cmake. This can be corrected by applying the following<br>
>> patch:<br>
>> -  find_file(_file_name ${file} ${PROJECT_SOURCE_DIR} /)<br>
>> +  find_file(_file_name "${file}" "${PROJECT_SOURCE_DIR}" /<br>
>> NO_CMAKE_FIND_ROOT_PATH)<br>
>> in both function. This will force find_file to ignore the<br>
>> CMAKE_FIND_ROOT_PATH for these functions. This is fine since they seem<br>
>> to be used only to refer to local files.<br>
>><br>
>> ======== OpenCV ========<br>
>> In OpenCV, the Makefile does not use the toolchain file. I've modified<br>
>> mine as follows. There might cleaner ways to get the same semantic.<br>
>> CMAKE = cmake<br>
>> TOOLCHAIN =<br>
>> ifeq (x$(wildcard<br>
>> $(ROS_ROOT)/rostoolchain.cmake),x$(ROS_ROOT)/rostoolchain.cmake)<br>
>>      TOOLCHAIN = -DCMAKE_TOOLCHAIN_FILE=$(ROS_ROOT)/rostoolchain.cmake<br>
>> endif<br>
>> CMAKE_ARGS = $(TOOLCHAIN) -D CMAKE_BUILD_TYPE=RELEASE \<br>
>>               -D CMAKE_INSTALL_PREFIX=`rospack find<br>
>> opencv2`/$(INSTALL_DIR) \<br>
>>               ...<br>
>> =========================<br>
>> Next thing is to find a way to generate rospack and rosstack twice, once<br>
>> for host, another for deployment, and to call a different one during<br>
>> compilation and at runtime. Any idea?<br>
>><br>
>> HTH<br>
>><br>
>> --<br>
>> Dr. Cedric Pradalier<br>
>> <a href="http://www.asl.ethz.ch/people/cedricp" target="_blank">http://www.asl.ethz.ch/people/cedricp</a><br>
>><br>
>> _______________________________________________<br>
>> ros-users mailing list<br>
>> <a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
>> <a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
>><br>
>><br>
><br>
><br>
><br>
<br>
<br>
--<br>
Dr. Cedric Pradalier<br>
<a href="http://www.asl.ethz.ch/people/cedricp" target="_blank">http://www.asl.ethz.ch/people/cedricp</a><br>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Phone : +82-10-5400-3296 (010-5400-3296)<br>Home: <a href="http://snorriheim.dnsdojo.com/">http://snorriheim.dnsdojo.com/</a><br>Yujin Robot: <a href="http://www.yujinrobot.com/">http://www.yujinrobot.com/</a><br>
Embedded Control Libraries: <a href="http://snorriheim.dnsdojo.com/redmine/wiki/ecl">http://snorriheim.dnsdojo.com/redmine/wiki/ecl</a><br>