autoproj 1.7.0.rc2 → 1.7.0

data/doc/guide/src/package_sets/manifest-xml.page

@@ -1,29 +0,0 @@
----
-title: The manifest.xml file
-sort_info: 120
----
-
-The manifest.xml is an optional (but *very recommended*) file that lies in the
-root of every source package. This file describes both what the package *is*
-(i.e. short description, contact information), and dependency information (what
-should be installed for that package to be built successfully).
-
-The general form of the file is:
-
-{coderay:: xml}
-<package>
-  <description brief="one line of text">
-    long description goes here, 
-    <em>XHTML is allowed</em>
-  </description>
-  <author>Alice/alice@somewhere.bar, Bob/bob@nowhere.foo</author>
-  <license>BSD</license>
-  <url>http://sites.google.com/site/rubyinmotion</url>
-  <logo>http://sites.google.com/site/rubyinmotion</logo>
-
-  <depend package="pkgname"/> <!-- add dependency on either another
-                               autoproj-built package, or an OS-provided one -->
-  <depend package="common"/>
-</package>
-{coderay}
-

data/doc/guide/src/package_sets/osdeps.page

@@ -1,128 +0,0 @@
----
-title: Operating System dependencies
-sort_info: 300
----
-
-Autoproj offers the possibility to use OS-packaged software instead of building
-it, to leverage the underlying platform's software. This page details how it's
-done.
-
-Defining dependencies between source packages and OS packages
--------------------------------------------------------------
-
-If a source package depends on an OS package, this dependency should be declared
-in the same way than between  source packages:
-
- * either by adding the <depend package="os_dep_name" /> tag in the
-   manifest.xml, or
- * by calling #depends_on("os_dep_name") in the autobuild file.
-
-The os_dep_name above being the name of the package as declared in the OS
-dependencies files defined below.
-
-During the build, autoproj looks first for OS dependencies. If no dependency is
-available for that particular platform, it will then look for a source package
-definition and build it. If none of the two exist, an error is returned.
-
-OS packages
------------
-
-The general format of the an OS package definition:
-
-~~~~~~~~~~~~~~~~~~
-name:
-    distribution1,distribution2:
-        version1,version2: [package_name1, package_name2]
-~~~~~~~~~~~~~~~~~~
-
-Where 'name' is the name used to declare the dependency (see above), `distribution`
-the name of the distribution and <tt>version</tt> the
-distribution's version, and <tt>package_name</tt> the name of the package in
-the underlying OS.
-
-Since the osdeps file is a YAML file, it could also be written
-
-~~~~~~~~~~~~~~~~~~
-name:
-    distribution1,distribution2:
-        version1,version2:
-            - package_name1
-            - package_name2
-~~~~~~~~~~~~~~~~~~
-
-If only one package needs to be installed, one can use the shortcut
-
-~~~~~~~~~~~~~~~~~~
-name:
-    distribution1,distribution2:
-        version1,version2: package_name
-~~~~~~~~~~~~~~~~~~
-
-Finally, if the package name is version-independent, the version can be omitted:
-
-
-~~~~~~~~~~~~~~~~~~
-name:
-    distribution1,distribution2: package_name
-~~~~~~~~~~~~~~~~~~
-
-Examples:
-
-~~~~~~~~~~~~~~~~~~
-ruby:
-    debian,ubuntu:
-        9.04,10.04,sid: libruby-dev
-boost:
-    debian:
-        - libboost1.38-dev
-        - libboost-program1.38-dev
-    ubuntu:
-        9.04,10.04: libboost-dev
-~~~~~~~~~~~~~~~~~~
-
-At the time of this writing, autoproj is able to install packages on
-Ubuntu/Debian and Gentoo. Support for other operating systems can be easily
-added, so [contact me](http://github.com/doudou) if you want to do so.
-
-RubyGems packages
------------------
-
-RubyGems packages are OS-independent. In the osdeps files, they can be referred
-to by replacing the OS distribution name by 'gem'.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~
-hoe:
-    gem:
-        hoe
-~~~~~~~~~~~~~~~~~~
-
-If the OS dep name and the RubyGems name are the same, one can use the shortcut
-
-~~~~~~~~~~~~~~~~~~
-hoe: gem
-~~~~~~~~~~~~~~~~~~
-
-Note that it is possible to use a mixture of RubyGems and OS packages. For
-instance, the following snippet will both install the gnuplot package and the
-gnuplot RubyGems whenever an osdep on 'gnuplot' is declared.
-
-~~~~~~~~~~~~~~~~~~
-gnuplot:
-    gem: gnuplot
-    debian: gnuplot
-~~~~~~~~~~~~~~~~~~
-
-Ignoring some dependencies
---------------------------
-It is possible that, on some operating systems, a given package should simply be
-ignored. To do so, simply use the 'ignore' keyword. Example:
-
-~~~~~~~~~~~~~~~~~~
-gnuplot:
-    gem: gnuplot
-    debian: ignore
-    ubuntu: gnuplot
-~~~~~~~~~~~~~~~~~~
-

data/doc/guide/src/quick_start.page

@@ -1,128 +0,0 @@
----
-title: Quick start
-sort_info: 25
----
-
-Bootstrapping
--------------
-"Bootstrapping" means getting autoproj itself before it can work its magic ...
-The canonical way is the following:
-
- * install Ruby by yourself. On Debian or Ubuntu, this is done with
-   done with
-
-   sudo apt-get install wget ruby
-   {: .cmdline}
-
- * then, [download this script](autoproj_bootstrap) *in the directory where
-   you want to create an autoproj installation*, and run it. This can be done with
-
-   wget http://doudou.github.com/autoproj/autoproj\_bootstrap <br />
-   ruby autoproj\_bootstrap
-   {: .cmdline}
-
- * follow the instructions printed by the script<tt>manifest</tt>.
-
-Additionally, if you are given a reference to a source code repository in which
-an autoproj configuration is stored (i.e. a directory in which a manifest is
-present), you can bootstrap this configuration directly:
-
-   wget http://doudou.github.com/autoproj/autoproj\_bootstrap <br />
-   ruby autoproj\_bootstrap VCS 
-   {: .cmdline}
-
-For instance, to build all packages made available by the RubyInMotion project,
-do
-
-   wget http://doudou.github.com/autoproj/autoproj\_bootstrap <br />
-   ruby autoproj\_bootstrap git git://github.com/doudou/rubim.all.git
-   {: .cmdline}
-
-Additional options can be given for the version control system. For instance,
-
-   wget http://doudou.github.com/autoproj/autoproj\_bootstrap <br />
-   ruby autoproj\_bootstrap git git://github.com/doudou/rubim.all.git branch=stable
-   {: .cmdline}
-
-Switching configuration after bootstrapping
--------------------------------------------
-Let's assume that you want to switch what configuration autoproj is tracking,
-but without having to redo a complete bootstrap -- i.e. avoiding to rebuild
-stuff that is common between the configurations.
-
-autoproj provides the switch-config command for that. This command takes the
-same arguments than the bootstrap script, that is:
-
-autoproj switch-config \[vcs_type] \[vcs_url] \[vcs_options]
-{: .cmdline}
-
-As a shortcut, one can omit vcs_type and vcs_url if they don't change.
-This is especially useful when switching between branches:
-
-autoproj switch-config branch=experimental
-{: .cmdline}
-
-Management
-----------
-
-To build the packages, simply do:
-
-autoproj build
-{: .commandline}
-
-It will ask the value of newly defined configuration options, import code hosted
-remotely that is not yet present, install OS packages (e.g. Ubuntu packages on
-an Ubunut installation) and build everything.
-
-autoproj will *not* ask you again about the configuration questions you already
-answered, so if you want to change them, do:
-
-autoproj build --reconfigure
-{: .commandline}
-
-Alternatively, you can edit the autoproj/config.yml file directly.
-
-By default, autoproj does not automatically update the package sources. To do
-that, you have to explicitely call
-
-autoproj update
-{: .commandline}
-
-Finally, if you want to make sure that your build is fresh, then do
-
-autoproj rebuild
-{: .commandline}
-
-A less intrusive version of it only forces all tools to reconsider building. It
-is mainly useful for CMake when the build environment changed -- cmake caches a
-lot of values. To trigger this, do
-
-autoproj force-build
-{: .commandline}
-
-To add a new set, one edits the <tt>autoproj/manifest</tt> file and adds it
-there. Then, simply starting the build will update everything and rebuild what
-is needed.
-
-Documentation is generated only when asked explicitely:
-
-autoproj doc
-{: .commandline}
-
-It generates documentation of packages that have some, and copies that
-documentation into build/doc/, following the same layout than the source
-directory.
-
-All these commands (i.e. build, doc, and update) accept a package name as
-argument, thus triggering build only for this package and its dependencies. For
-instance:
-
-autoproj build orocos/rtt
-{: .commandline}
-
-**Exception**: to avoid long builds, the rebuild and force-build commands apply only
-to the packages given on the command line. E.g., autoproj rebuild orocos/rtt
-will only rebuild the orocos/rtt packages. If you want to rebuild both the
-packages and its dependencies, use the --with-depends options.
-{: .warning}
-

data/doc/guide/src/toc.page

@@ -1,7 +0,0 @@
----
-title: Table of Contents
-sort_info: -1
----
-
-{menu: {nested: true, used_nodes: all, min_levels: 10, max_levels: 10}}
-

data/doc/guide/src/writing_manifest.page

@@ -1,146 +0,0 @@
----
-title: The manifest file.
-sort_info: 50
----
-
-This page describes the structure of a autoproj installation, and describes how
-to manage one. See [the introduction](index.html) for the bootstrapping process.
-
-Structure
----------
-
-![Structure overview](overview.png)!
-{: .full}
-
-The autoproj configuration and build process goes like this:
-
- * a set of packages are declared in _package sets_. These package sets can
-   either be local (saved along with the rest of the autoproj configuration) or
-   remote (imported from a VCS). They declare how to get, build and install
-   a certain number of packages. On the image above, there are three of those
-   sets: rubim.base, rubim.orocos and rubim.drivers.
- * packages that are relevant to the local installation are cherry-picked from
-   the package sets. One can either select packages one-by-one (the case for the
-   two packages of rubim.drivers above), or a package set can be imported as a
-   whole (rubim.orocos and rubim.base).
- * autoproj will then import the selected packages, auto-select their
-   dependencies and import them as well, build and install all of this.
- * the selected packages can be imported and built in subdirectories of the
-   installation tree. In the above example, all packages from rubim.orocos are
-   built in the tools/ subdirectory, one package of rubim.drivers in the
-   perception/ subdirectory and so on.
-
-In practice, the autoproj configuration is saved in an autoproj/ directory. It
-is split like this:
-
- * autoproj/manifest: list of available package sets, package selection and
-   installation layout (where to put what).
- * autoproj/\*/: local sets, i.e. sets that have not been imported from a remote
-   version control system.
- * autoproj/remotes/\*/: package sets that are imported from a remote version
-   control system
- * autoproj/init.rb, autoproj/overrides.rb and autoproj/overrides.yml:
-   installation customization
-
-The build is done in two steps:
-
- * each package is being built in a <tt>build</tt> subdirectory of the package's
-   source (<tt>package_directory/build/</tt>)
- * it is then installed in the build/ directory at the toplevel of the autoproj
-   installation
-
-Moreover, the <tt>build/log</tt> directory contains the output of all commands
-that have been run during the build.
-
-Finally, a <tt>env.sh</tt> script is generated to set up your shell for the use
-of the installed software.
-
-Listing and adding package sets
--------------------------------
-Package sets are listed in the <tt>package_sets</tt> section of
-<tt>autoproj/manifest</tt> file. This section looks like this:
-
-{coderay:: yaml}
-package_sets:
-  - imoby
-  - type: git
-    url:  git://github.com/doudou/autoproj-orocos.git
-{coderay}
-
-It lists both local and remote sets that are available for this installation.
-Local sets are subdirectories of the <tt>autoproj/</tt> directory: for instance,
-in the above example, autoproj will look at the <tt>autoproj/imoby/</tt>
-directory. Remote sets are taken from remote version control systems. Its
-general format is:
-
-{coderay:: yaml}
-  - type: version_control_type # git, svn, cvs, darcs
-    url: repository_url
-{coderay}
-
-For the git importer, one of 'branch' or 'tag' options can be provided as well:
-{coderay:: yaml}
-  - type: version_control_type # git, svn, cvs, darcs
-    url: repository_url
-    branch: branch_to_track
-    tag: tag_to_stick_to # it is branch OR tag
-{coderay}
-
-Imported package sets are saved in the <tt>.remotes</tt> directory of the
-autoproj installation. The importers that are available for configuration are
-the same than the ones available for the packages themselves, so see [this
-page](package_sets/importers.html#all_importers) for the list of available importers.
-
-Listing the available packages.
------------------------------
-Once you have updated your manifest file to list all the package sets that you
-want to use, you can list all the packages that are now available with
-
-autoproj list-sets
-{: .commandline}
-
-Its output looks like this:
-
-<pre>
-rubim.orocos
-  local source in /home/doudou/dfki/imoby1.9/autoproj/orocos
-  packages:
-  | orocos/base      | git:/home/doudou/dfki/dfki-share/projects/all/Intelligent_Mobility/development/software/git/tools/orocos/base.git                           |
-  | orocos/logger    | git:/home/doudou/dfki/dfki-share/projects/all/Intelligent_Mobility/development/software/git/tools/orocos/logger.git branch=fast_log         |
-  | orocos/ocl       | git:/home/doudou/dfki/dfki-share/projects/all/Intelligent_Mobility/development/software/git/tools/orocos/ocl.git branch=rubim               |
-</pre>
-
-The first line is the **package set name**. It is defined in the package set's
-source.yml file and *does not have to be identical to the set's directory
-name*. In the example above, the package set is saved in autoproj/orocos but is
-called dfki.orocos.
-
-The second line tells you where this set comes from. It is local if it comes
-along with the main autoproj configuration (manifest and so on). It is remote
-if it is imported from a version control system.
-
-Finally comes the list of packages that are defined in this set, along with the
-importer setup (URL and options, as for instance branches for orocos/logger
-above).
-
-Picking the packages to build
------------------------------
-If you do not wish to build all the packages that are available (you rarely
-wish that), you have to list the desired packages in your manifest file.
-
-To do so, you will have to create a <tt>layout</tt> section and list the
-desired packages:
-
-{coderay:: yaml}
-layout:
-    - rubim.base
-    - orocos/rtt
-    - orocos/logger
-{coderay}
-
-This layout can either list packages one by one, but complete package sets can
-also be selected (the rubim.base above)
-
-More advanced mechanisms are available to customize this list. These mechanisms
-are [detailed here](customization.html)
-