diamondback:Only showing information from the released package extracted on Unknown. No API documentation available. Please see this page for information on how to submit your repository to our index.
electric:Documentation generated on Unknown
fuerte:Documentation generated on January 02, 2014 at 11:52 AM
groovy:Documentation generated on October 06, 2014 at 06:51 AM
hydro:Documentation generated on August 27, 2015 at 02:46 PM (doc job).
indigo:Documentation generated on June 09, 2019 at 04:23 AM (doc job).
jade:Documentation generated on March 09, 2017 at 12:45 PM (doc job).
kinetic:Documentation generated on April 30, 2020 at 06:27 AM (doc job).
lunar:Documentation generated on April 02, 2019 at 10:10 AM (doc job).
melodic:Documentation generated on March 01, 2022 at 07:24 AM (doc job).
noetic:Documentation generated on March 02, 2022 at 08:49 AM (doc job).
A collection of .mk include files for building ROS architectural elements. Most package authors should use cmake .mk, which calls CMake for the build of the package. The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
A collection of .mk include files for building ROS architectural elements. Most package authors should use cmake .mk, which calls CMake for the build of the package. The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
A collection of .mk include files for building ROS architectural elements. Most package authors should use cmake .mk, which calls CMake for the build of the package. The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Dirk Thomas <dthomas AT osrfoundation DOT org>
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Dirk Thomas <dthomas AT osrfoundation DOT org>
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Dirk Thomas <dthomas AT osrfoundation DOT org>
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Dirk Thomas <dthomas AT osrfoundation DOT org>
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Dirk Thomas <dthomas AT osrfoundation DOT org>
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Dirk Thomas <dthomas AT osrfoundation DOT org>
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Dirk Thomas <dthomas AT osrfoundation DOT org>
A collection of .mk include files for building ROS architectural elements.
Most package authors should use cmake .mk, which calls CMake for the build of the package.
The other files in this package are intended for use in exotic situations that mostly arise when importing 3rdparty code.
Maintainer status: maintained
Maintainer: Michel Hidalgo <michel AT ekumenlabs DOT com>, Jacob Perron <jacob AT openrobotics DOT org>
Author: Brian Gerkey, Morgan Quigley, Dirk Thomas <dthomas AT openrobotics DOT org>
NOTE: when using rospack to find the mk-package, the ROS_PACKAGE_PATH needs to be set accordingly. Thus, you should have a dependency to roslib in your package.xml, as this provides the respective environment hooks that set this.
CMake-driven builds
Most packages, and all stacks, use CMake to build. But every package must provide a Makefile if it does any building. The following files are provided to simplify the Makefile in most packages, and all stacks:
The following variables should be defined prior to including download_unpack_build.mk:
TARBALL: local path to which the tarball should be downloaded; it must start with build/
TARBALL_URL: fully-qualified URL from which to retrieve the tarball
SOURCE_DIR: source directory that you want the tarball unpacked into; it must start with build/
INITIAL_DIR (optional): the name that the tarball will naturally unpack into, if different from SOURCE_DIR; it must start with build/
UNPACK_CMD (optional): the command to apply to the tarball to unpack it (default: tar xzf)
MD5SUM_FILE (optional, but highly recommended): The name of a file containing the md5 hash of the tarball, in the format produced by the UNIX command md5sum
TARBALL_PATCH (optional): a list of patch files to apply to the tarball after unpacking (e.g. 'TARBALL_PATCH = patch1.patch patch2.patch')
After including download_unpack_build.mk, you can make targets depend on the $(SOURCE_DIR)/unpacked file; it will be created (and updated) after the tarball has been downloaded, unpacked, and (optionally) patched.
For a 3rdparty package that pulls code from an SVN repository, you should use svn_checkout.mk, like so:
all: installed
SVN_DIR = build/stage-svn
SVN_URL = https://playerstage.svn.sourceforge.net/svnroot/playerstage/code/stage/branches/stage-ros
SVN_REVISION = -r 8262
include $(shell rospack find mk)/svn_checkout.mk
installed: $(SVN_DIR) patched Makefile.stage
cd $(SVN_DIR) && autoreconf -i -s
cd $(SVN_DIR) && ./configure --prefix=`pwd`/../..
cd $(SVN_DIR) && make install
touch installed
clean:
-cd $(SVN_DIR) && make clean
rm -rf stage installed patched
wipe: clean
rm -rf $(SVN_DIR)
The following variables should be defined prior to including svn_checkout.mk:
SVN_DIR: the name of the local working copy to be created
SVN_URL: the URL of the repository to check out from
SVN_REVISION (optional, but highly recommended): the revision to check out at, including the -r flag (e.g., -r 8262)
SVN_CMDLINE (optional): how to invoke svn (useful if you want to pass extra arguments, e.g. svn --non-interactive)
SVN_PATCH: list of patch files to apply to the working copy after checkout
After including svn_checkout.mk, you can make your targets depend on the patched file; it will be created after the working copy is checked out and (optionally) patched.