[Buildroot] [PATCH 00/13] Documentation updates and improvements

[Buildroot] [PATCH 00/13] Documentation updates and improvements

[Thomas Petazzoni]

Hello,

Here is a set of documentation updates and improvements, about
toolchains, package infrastructures, dependency and build-time
graphing, and also finally a documentation about
<pkg>_OVERRIDE_SRCDIR.

Thomas

Thomas Petazzoni (13):
  docs/manual: toolchain packages no longer use custom makefiles
  docs/manual: rephrase part about rebuilding packages
  docs/manual: rephrase and expand part on when a full rebuild is
    necessary
  docs/manual: reference Python and Lua infras from the list of package
    infrastructures
  docs/manual: add section about dependency graphs
  docs/manual: add section about build time graphing
  docs/manual: update informations about C library in internal backend
  docs/manual: update external toolchain examples
  docs/manual: mention that custom toolchains is also useful for BR
    toolchains
  docs/manual: rephrase paragraph about unsupported external toolchains
  docs/manual: refresh informations about *-menuconfig targets
  docs/manual: document the usage of <pkg>_OVERRIDE_SRCDIR
  docs/manual: mention the per-package graph-depends target

 docs/manual/adding-packages-directory.txt   |  11 +++
 docs/manual/advanced.txt                    |   2 +
 docs/manual/common-usage.txt                |  99 +++++++++++++++++++++
 docs/manual/configure.txt                   |  77 ++++++----------
 docs/manual/make-tips.txt                   |   6 +-
 docs/manual/package-make-target.txt         |   5 ++
 docs/manual/rebuilding-packages.txt         | 132 +++++++++++++++++++---------
 docs/manual/using-buildroot-development.txt |  84 ++++++++++++++++++
 8 files changed, 324 insertions(+), 92 deletions(-)
 create mode 100644 docs/manual/using-buildroot-development.txt

-- 
1.8.3.2

[Buildroot] [PATCH 01/13] docs/manual: toolchain packages no longer use custom makefiles

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/rebuilding-packages.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/docs/manual/rebuilding-packages.txt b/docs/manual/rebuilding-packages.txt
index 88d6670..da8d230 100644
--- a/docs/manual/rebuilding-packages.txt
+++ b/docs/manual/rebuilding-packages.txt
@@ -69,8 +69,5 @@ files that just tell whether this or that action has been done):
   Buildroot will trigger the recompilation of the package from the
   compilation step (execution of +make+).
 
-Note: toolchain packages use custom makefiles. Their stamp files are named
-differently.
-
 Further details about package special make targets are explained in
 xref:pkg-build-steps[].
-- 
1.8.3.2

[Buildroot] [PATCH 01/13] docs/manual: toolchain packages no longer use custom makefiles

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regard,
Yann E. MORIN.

> ---
>  docs/manual/rebuilding-packages.txt | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/docs/manual/rebuilding-packages.txt b/docs/manual/rebuilding-packages.txt
> index 88d6670..da8d230 100644
> --- a/docs/manual/rebuilding-packages.txt
> +++ b/docs/manual/rebuilding-packages.txt
> @@ -69,8 +69,5 @@ files that just tell whether this or that action has been done):
>    Buildroot will trigger the recompilation of the package from the
>    compilation step (execution of +make+).
>  
> -Note: toolchain packages use custom makefiles. Their stamp files are named
> -differently.
> -
>  Further details about package special make targets are explained in
>  xref:pkg-build-steps[].
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 02/13] docs/manual: rephrase part about rebuilding packages

[Thomas Petazzoni]

There is no need to tell people should remove stamp files: they should
use the make <pkg>-reconfigure and make <pkg>-rebuild make targets
instead. We still keep an explanation about stamp files, just to give
to the user an insight on how Buildroot works internally.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/rebuilding-packages.txt | 36 +++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/docs/manual/rebuilding-packages.txt b/docs/manual/rebuilding-packages.txt
index da8d230..4872e88 100644
--- a/docs/manual/rebuilding-packages.txt
+++ b/docs/manual/rebuilding-packages.txt
@@ -51,23 +51,25 @@ its build directory in +output/build+. Buildroot will then re-extract,
 re-configure, re-compile and re-install this package from scratch. You
 can ask buildroot to do this with the +make <package>-dirclean+ command.
 
-For convenience, the special make targets
-<package>-reconfigure and <package>-rebuild repeat the configure
-resp. build steps.
-
-However, if you don't want to rebuild the package completely from
-scratch, a better understanding of the Buildroot internals is
-needed. Internally, to keep track of which steps have been done and
-which steps remain to be done, Buildroot maintains stamp files (empty
-files that just tell whether this or that action has been done):
-
-* +output/build/<package>-<version>/.stamp_configured+. If removed,
-  Buildroot will trigger the recompilation of the package from the
-  configuration step (execution of +./configure+).
-
-* +output/build/<package>-<version>/.stamp_built+. If removed,
-  Buildroot will trigger the recompilation of the package from the
-  compilation step (execution of +make+).
+On the other hand, if you only want to restart the build process of a
+package from its compilation step, you can run +make
+<package>-rebuild+, followed by +make+ or +make <package>+. It will
+restart the compilation and installation of the package, but not from
+scratch: it basically simply re-executes +make+ and +make install+
+inside the package, so it will only rebuild files that changed.
+
+If you want to restart the build process of a package from its
+configuration step, you can run +make <package>-reconfigure+, followed
+by +make+ or +make <package>+. It will restart the configuration,
+compilation and installation of the package.
+
+Internally, Buildroot creates so-called _stamp files_ to keep track of
+which build steps have been completed for each package. They are
+stored in the package build directory,
++output/build/<package>-<version>/+ and are named
++.stamp_<step-name>+. The commands detailed above simply manipulate
+these stamp files to force Buildroot to restart a specific set of
+steps of a package build process.
 
 Further details about package special make targets are explained in
 xref:pkg-build-steps[].
-- 
1.8.3.2

[Buildroot] [PATCH 02/13] docs/manual: rephrase part about rebuilding packages

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> There is no need to tell people should remove stamp files: they should
> use the make <pkg>-reconfigure and make <pkg>-rebuild make targets
> instead. We still keep an explanation about stamp files, just to give
> to the user an insight on how Buildroot works internally.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  docs/manual/rebuilding-packages.txt | 36 +++++++++++++++++++-----------------
>  1 file changed, 19 insertions(+), 17 deletions(-)
> 
> diff --git a/docs/manual/rebuilding-packages.txt b/docs/manual/rebuilding-packages.txt
> index da8d230..4872e88 100644
> --- a/docs/manual/rebuilding-packages.txt
> +++ b/docs/manual/rebuilding-packages.txt
> @@ -51,23 +51,25 @@ its build directory in +output/build+. Buildroot will then re-extract,
>  re-configure, re-compile and re-install this package from scratch. You
>  can ask buildroot to do this with the +make <package>-dirclean+ command.
>  
> -For convenience, the special make targets
> -<package>-reconfigure and <package>-rebuild repeat the configure
> -resp. build steps.
> -
> -However, if you don't want to rebuild the package completely from
> -scratch, a better understanding of the Buildroot internals is
> -needed. Internally, to keep track of which steps have been done and
> -which steps remain to be done, Buildroot maintains stamp files (empty
> -files that just tell whether this or that action has been done):
> -
> -* +output/build/<package>-<version>/.stamp_configured+. If removed,
> -  Buildroot will trigger the recompilation of the package from the
> -  configuration step (execution of +./configure+).
> -
> -* +output/build/<package>-<version>/.stamp_built+. If removed,
> -  Buildroot will trigger the recompilation of the package from the
> -  compilation step (execution of +make+).
> +On the other hand, if you only want to restart the build process of a
> +package from its compilation step, you can run +make
> +<package>-rebuild+, followed by +make+ or +make <package>+. It will
> +restart the compilation and installation of the package, but not from
> +scratch: it basically simply re-executes +make+ and +make install+
> +inside the package, so it will only rebuild files that changed.
> +
> +If you want to restart the build process of a package from its
> +configuration step, you can run +make <package>-reconfigure+, followed
> +by +make+ or +make <package>+. It will restart the configuration,
> +compilation and installation of the package.
> +
> +Internally, Buildroot creates so-called _stamp files_ to keep track of
> +which build steps have been completed for each package. They are
> +stored in the package build directory,
> ++output/build/<package>-<version>/+ and are named
> ++.stamp_<step-name>+. The commands detailed above simply manipulate
> +these stamp files to force Buildroot to restart a specific set of
> +steps of a package build process.
>  
>  Further details about package special make targets are explained in
>  xref:pkg-build-steps[].
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 03/13] docs/manual: rephrase and expand part on when a full rebuild is necessary

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/rebuilding-packages.txt | 93 ++++++++++++++++++++++++++++---------
 1 file changed, 71 insertions(+), 22 deletions(-)

diff --git a/docs/manual/rebuilding-packages.txt b/docs/manual/rebuilding-packages.txt
index 4872e88..26e244c 100644
--- a/docs/manual/rebuilding-packages.txt
+++ b/docs/manual/rebuilding-packages.txt
@@ -5,33 +5,82 @@
 Understanding when a full rebuild is necessary
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A full rebuild is achieved by running:
+Buildroot does not attempt to detect what parts of the system should
+be rebuilt when the system configuration is changed through +make
+menuconfig+, +make xconfig+ or one of the other configuration
+tools. In some cases, Buildroot should rebuild the entire system, in
+some cases, only a specific subset of packages. But detecting this in
+a completely reliable manner is very difficult, and therefore the
+Buildroot developers have decided to simply not attempt to do this.
+
+Instead, it is the responsibility of the user to know when a full
+rebuild is necessary. As a hint, here are a few rules of thumb that
+can help you understand how to work with Buildroot:
+
+ * When the target architecture configuration is changed, a complete
+   rebuild is needed. Changing the architecture variant, the binary
+   format or the floating point strategy for example has an impact on
+   the entire system.
+
+ * When the toolchain configuration is changed, a complete rebuild
+   generally is needed. Changing the toolchain configuration often
+   involves changing the compiler version, the type of C library or
+   its configuration, or some other fundamental configuration item,
+   and these changes have an impact on the entire system.
+
+ * When an additional package is added to the configuration, a full
+   rebuild is not necessarily needed. Buildroot will detect that this
+   package has never been built, and will build it. However, if this
+   package is a library that can optionally be used by packages that
+   have already been built, Buildroot will not automatically rebuild
+   those. Either you know which packages should be rebuilt, and you
+   can rebuild them manually, or you should do a full rebuild. For
+   example, let's suppose you have built a system with the +ctorrent+
+   package, but without +openssl+. Your system works, but you realize
+   you would like to have SSL support in +ctorrent+, so you enable the
+   +openssl+ package in Buildroot configuration and restart the
+   build. Buildroot will detect that +openssl+ should be built and
+   will be build it, but it will not detect that +ctorrent+ should be
+   rebuilt to benefit from +openssl+ to add OpenSSL support. You will
+   either have to do a full rebuild, or rebuild +ctorrent+ itself.
+
+ * When a package is removed from the configuration, Buildroot does
+   not do anything special. It does not remove the files installed by
+   this package from the target root filesystem or from the toolchain
+   _sysroot_. A full rebuild is needed to get rid of this
+   package. However, generally you don't necessarily need this package
+   to be removed right now: you can wait for the next lunch break to
+   restart the build from scratch.
+
+ * When the sub-options of a package are changed, the package is not
+   automatically rebuilt. After making such changes, rebuilding only
+   this package is often sufficient, unless enabling the package
+   sub-option adds some features to the package that are useful for
+   another package which has already been built. Again, Buildroot does
+   not track when a package should be rebuilt: once a package has been
+   built, it is never rebuilt unless explicitly told to do so.
+
+ * When a change to the root filesystem skeleton is made, a full
+   rebuild is needed. However, when changes to the root filesystem
+   overlay, to a post-build script or a post-image script are made,
+   there is no need for a full rebuild: a simple +make+ invocation
+   will take the changes into account.
+
+Generally speaking, when you're facing a build error and you're unsure
+of the potential consequences of the configuration changes you've
+made, do a full rebuild. If you get the same build error, then you are
+sure that the error is not related to partial rebuilds of packages,
+and if this error occurs with packages from the official Buildroot, do
+not hesitate to report the problem! As your experience with Buildroot
+progresses, you will progressively learn when a full rebuild is really
+necessary, and you will save more and more time.
+
+For reference, a full rebuild is achieved by running:
 
 ---------------
 $ make clean all
 ---------------
 
-In some cases, a full rebuild is mandatory:
-
-* each time the toolchain properties are changed, this includes:
-
-** after changing any toolchain option under the _Toolchain_ menu (if
-   the internal Buildroot backend is used);
-** after running +make uclibc-menuconfig+.
-
-* after removing some libraries from the package selection.
-
-In some cases, a full rebuild is recommended:
-
-* after adding some libraries to the package selection (otherwise,
-  packages that can be optionally linked against those libraries
-  won't be rebuilt, so they won't support those new available
-  features).
-
-In other cases, it is up to you to decide if you should run a
-full rebuild, but you should know what is impacted and understand what
-you are doing anyway.
-
 [[rebuild-pkg]]
 Understanding how to rebuild packages
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
1.8.3.2

[Buildroot] [PATCH 03/13] docs/manual: rephrase and expand part on when a full rebuild is necessary

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  docs/manual/rebuilding-packages.txt | 93 ++++++++++++++++++++++++++++---------
>  1 file changed, 71 insertions(+), 22 deletions(-)
> 
> diff --git a/docs/manual/rebuilding-packages.txt b/docs/manual/rebuilding-packages.txt
> index 4872e88..26e244c 100644
> --- a/docs/manual/rebuilding-packages.txt
> +++ b/docs/manual/rebuilding-packages.txt
> @@ -5,33 +5,82 @@
>  Understanding when a full rebuild is necessary
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> -A full rebuild is achieved by running:
> +Buildroot does not attempt to detect what parts of the system should
> +be rebuilt when the system configuration is changed through +make
> +menuconfig+, +make xconfig+ or one of the other configuration
> +tools. In some cases, Buildroot should rebuild the entire system, in
> +some cases, only a specific subset of packages. But detecting this in
> +a completely reliable manner is very difficult, and therefore the
> +Buildroot developers have decided to simply not attempt to do this.
> +
> +Instead, it is the responsibility of the user to know when a full
> +rebuild is necessary. As a hint, here are a few rules of thumb that
> +can help you understand how to work with Buildroot:
> +
> + * When the target architecture configuration is changed, a complete
> +   rebuild is needed. Changing the architecture variant, the binary
> +   format or the floating point strategy for example has an impact on
> +   the entire system.
> +
> + * When the toolchain configuration is changed, a complete rebuild
> +   generally is needed. Changing the toolchain configuration often
> +   involves changing the compiler version, the type of C library or
> +   its configuration, or some other fundamental configuration item,
> +   and these changes have an impact on the entire system.
> +
> + * When an additional package is added to the configuration, a full
> +   rebuild is not necessarily needed. Buildroot will detect that this
> +   package has never been built, and will build it. However, if this
> +   package is a library that can optionally be used by packages that
> +   have already been built, Buildroot will not automatically rebuild
> +   those. Either you know which packages should be rebuilt, and you
> +   can rebuild them manually, or you should do a full rebuild. For
> +   example, let's suppose you have built a system with the +ctorrent+
> +   package, but without +openssl+. Your system works, but you realize
> +   you would like to have SSL support in +ctorrent+, so you enable the
> +   +openssl+ package in Buildroot configuration and restart the
> +   build. Buildroot will detect that +openssl+ should be built and
> +   will be build it, but it will not detect that +ctorrent+ should be
> +   rebuilt to benefit from +openssl+ to add OpenSSL support. You will
> +   either have to do a full rebuild, or rebuild +ctorrent+ itself.
> +
> + * When a package is removed from the configuration, Buildroot does
> +   not do anything special. It does not remove the files installed by
> +   this package from the target root filesystem or from the toolchain
> +   _sysroot_. A full rebuild is needed to get rid of this
> +   package. However, generally you don't necessarily need this package
> +   to be removed right now: you can wait for the next lunch break to
> +   restart the build from scratch.
> +
> + * When the sub-options of a package are changed, the package is not
> +   automatically rebuilt. After making such changes, rebuilding only
> +   this package is often sufficient, unless enabling the package
> +   sub-option adds some features to the package that are useful for
> +   another package which has already been built. Again, Buildroot does
> +   not track when a package should be rebuilt: once a package has been
> +   built, it is never rebuilt unless explicitly told to do so.
> +
> + * When a change to the root filesystem skeleton is made, a full
> +   rebuild is needed. However, when changes to the root filesystem
> +   overlay, to a post-build script or a post-image script are made,
> +   there is no need for a full rebuild: a simple +make+ invocation
> +   will take the changes into account.
> +
> +Generally speaking, when you're facing a build error and you're unsure
> +of the potential consequences of the configuration changes you've
> +made, do a full rebuild. If you get the same build error, then you are
> +sure that the error is not related to partial rebuilds of packages,
> +and if this error occurs with packages from the official Buildroot, do
> +not hesitate to report the problem! As your experience with Buildroot
> +progresses, you will progressively learn when a full rebuild is really
> +necessary, and you will save more and more time.
> +
> +For reference, a full rebuild is achieved by running:
>  
>  ---------------
>  $ make clean all
>  ---------------
>  
> -In some cases, a full rebuild is mandatory:
> -
> -* each time the toolchain properties are changed, this includes:
> -
> -** after changing any toolchain option under the _Toolchain_ menu (if
> -   the internal Buildroot backend is used);
> -** after running +make uclibc-menuconfig+.
> -
> -* after removing some libraries from the package selection.
> -
> -In some cases, a full rebuild is recommended:
> -
> -* after adding some libraries to the package selection (otherwise,
> -  packages that can be optionally linked against those libraries
> -  won't be rebuilt, so they won't support those new available
> -  features).
> -
> -In other cases, it is up to you to decide if you should run a
> -full rebuild, but you should know what is impacted and understand what
> -you are doing anyway.
> -
>  [[rebuild-pkg]]
>  Understanding how to rebuild packages
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 04/13] docs/manual: reference Python and Lua infras from the list of package infrastructures

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/adding-packages-directory.txt | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt
index 754a145..eff92fa 100644
--- a/docs/manual/adding-packages-directory.txt
+++ b/docs/manual/adding-packages-directory.txt
@@ -323,5 +323,16 @@ different way, using different infrastructures:
    CMake. We cover them through a xref:cmake-package-tutorial[tutorial]
    and xref:cmake-package-reference[reference].
 
+* *Makefiles for Python modules*: We have a dedicated infrastructure
+   for Python modules that use either the +distutils+ or the
+   +setuptools+ mechanism. We cover them through a
+   xref:python-package-tutorial[tutorial] and
+   xref:python-package-reference[reference].
+
+* *Makefiles for Lua modules*: We have a dedicated infrastructure for
+   Lua modules available through the LuaRocks web site. We cover them
+   through a xref:luarocks-package-tutorial[tutorial] and
+   xref:luarocks-package-reference[reference].
+
 Further formatting details: see xref:writing-rules-mk[the writing
 rules].
-- 
1.8.3.2

[Buildroot] [PATCH 04/13] docs/manual: reference Python and Lua infras from the list of package infrastructures

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> ---
>  docs/manual/adding-packages-directory.txt | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt
> index 754a145..eff92fa 100644
> --- a/docs/manual/adding-packages-directory.txt
> +++ b/docs/manual/adding-packages-directory.txt
> @@ -323,5 +323,16 @@ different way, using different infrastructures:
>     CMake. We cover them through a xref:cmake-package-tutorial[tutorial]
>     and xref:cmake-package-reference[reference].
>  
> +* *Makefiles for Python modules*: We have a dedicated infrastructure
> +   for Python modules that use either the +distutils+ or the
> +   +setuptools+ mechanism. We cover them through a
> +   xref:python-package-tutorial[tutorial] and
> +   xref:python-package-reference[reference].

I believe english grammar mandates the following:
    [...] a tutorial and a reference.

So, you're missing an 'a' between the 'and' and the 'reference'.

Also, what about the mandatory status of this? For other package
onfrastructures, we say:
    This infrastructure must be used for new packages that rely on [XXX]
    as their build system.

Why don't we add this for Python modules?

> +* *Makefiles for Lua modules*: We have a dedicated infrastructure for
> +   Lua modules available through the LuaRocks web site. We cover them
> +   through a xref:luarocks-package-tutorial[tutorial] and
> +   xref:luarocks-package-reference[reference].

Ditto 'a' and ditto 'mandatory'.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 04/13] docs/manual: reference Python and Lua infras from the list of package infrastructures

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Sun, 23 Feb 2014 16:29:57 +0100, Yann E. MORIN wrote:

> > +* *Makefiles for Python modules*: We have a dedicated infrastructure
> > +   for Python modules that use either the +distutils+ or the
> > +   +setuptools+ mechanism. We cover them through a
> > +   xref:python-package-tutorial[tutorial] and
> > +   xref:python-package-reference[reference].
> 
> I believe english grammar mandates the following:
>     [...] a tutorial and a reference.
> 
> So, you're missing an 'a' between the 'and' and the 'reference'.

Ok. I'll see if Peter applies the patch and makes the change himself
before resending 13 patches :-)

> Also, what about the mandatory status of this? For other package
> onfrastructures, we say:
>     This infrastructure must be used for new packages that rely on [XXX]
>     as their build system.
> 
> Why don't we add this for Python modules?

I found it quite redundant, and in fact I believe it is now a bit
useless even for autotools and cmake packages. It used to be useful at
the time we had old-style packages that were not yet converted. But
nowadays, it is quite clear that if the package infrastructure exists
and matches the build system of a given package, then it must be used.

Thanks a lot for the review!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 05/13] docs/manual: add section about dependency graphs

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/common-usage.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/docs/manual/common-usage.txt b/docs/manual/common-usage.txt
index 9a8c92a..bef42c6 100644
--- a/docs/manual/common-usage.txt
+++ b/docs/manual/common-usage.txt
@@ -149,3 +149,55 @@ of an ext2 filesystem may be corrupted; or, if you have sparse files in
 your filesystem, those parts may not be all-zeroes when read back). You
 should only use sparse files when handling files on the build machine, not
 when transferring them to an actual device that will be used on the target.
+
+Graphing the dependencies between packages
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[graph-depends]]
+
+One of Buildroot's jobs is to know the dependencies between packages,
+and make sure they are built in the right order. These dependencies
+can sometimes be quite complicated, and for a given system, it is
+often not easy to understand why such or such package was brought into
+the build by Buildroot.
+
+In order to help understanding the dependencies, and therefore better
+understand what is the role of the different components in your
+embedded Linux system, Buildroot is capable of generating dependency
+graphs.
+
+To generate a dependency graph of the full system you have compiled,
+simply run:
+
+------------------------
+make graph-depends
+------------------------
+
+You will find the generated graph in
++output/graphs/graph-depends.pdf+.
+
+If your system is quite large, the dependency graph may be too complex
+and difficult to read. It is therefore possible to generate the
+dependency graph just for a given package:
+
+------------------------
+make <pkg>-graph-depends
+------------------------
+
+You will find the generated graph in
++output/graph/<pkg>-graph-depends.pdf+.
+
+Note that the dependency graphs are generated using the +dot+ tool
+from the _Graphviz_ project, which you must have installed on your
+system to use this feature. In most distributions, it is available as
+the +graphviz+ package.
+
+By default, the dependency graphs are generated in the PDF
+format. However, by passing the +GRAPH_OUT+ environment variable, you
+can switch to other output formats, such as PNG, PostScript or
+SVG. All formats supported by the +-T+ option of the +dot+ tool are
+supported.
+
+--------------------------------
+GRAPH_OUT=svg make graph-depends
+--------------------------------
-- 
1.8.3.2

[Buildroot] [PATCH 05/13] docs/manual: add section about dependency graphs

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  docs/manual/common-usage.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/docs/manual/common-usage.txt b/docs/manual/common-usage.txt
> index 9a8c92a..bef42c6 100644
> --- a/docs/manual/common-usage.txt
> +++ b/docs/manual/common-usage.txt
> @@ -149,3 +149,55 @@ of an ext2 filesystem may be corrupted; or, if you have sparse files in
>  your filesystem, those parts may not be all-zeroes when read back). You
>  should only use sparse files when handling files on the build machine, not
>  when transferring them to an actual device that will be used on the target.
> +
> +Graphing the dependencies between packages
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +[[graph-depends]]
> +
> +One of Buildroot's jobs is to know the dependencies between packages,
> +and make sure they are built in the right order. These dependencies
> +can sometimes be quite complicated, and for a given system, it is
> +often not easy to understand why such or such package was brought into
> +the build by Buildroot.
> +
> +In order to help understanding the dependencies, and therefore better
> +understand what is the role of the different components in your
> +embedded Linux system, Buildroot is capable of generating dependency
> +graphs.
> +
> +To generate a dependency graph of the full system you have compiled,
> +simply run:
> +
> +------------------------
> +make graph-depends
> +------------------------
> +
> +You will find the generated graph in
> ++output/graphs/graph-depends.pdf+.
> +
> +If your system is quite large, the dependency graph may be too complex
> +and difficult to read. It is therefore possible to generate the
> +dependency graph just for a given package:
> +
> +------------------------
> +make <pkg>-graph-depends
> +------------------------
> +
> +You will find the generated graph in
> ++output/graph/<pkg>-graph-depends.pdf+.
> +
> +Note that the dependency graphs are generated using the +dot+ tool
> +from the _Graphviz_ project, which you must have installed on your
> +system to use this feature. In most distributions, it is available as
> +the +graphviz+ package.
> +
> +By default, the dependency graphs are generated in the PDF
> +format. However, by passing the +GRAPH_OUT+ environment variable, you
> +can switch to other output formats, such as PNG, PostScript or
> +SVG. All formats supported by the +-T+ option of the +dot+ tool are
> +supported.
> +
> +--------------------------------
> +GRAPH_OUT=svg make graph-depends
> +--------------------------------
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 06/13] docs/manual: add section about build time graphing

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/common-usage.txt | 47 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/docs/manual/common-usage.txt b/docs/manual/common-usage.txt
index bef42c6..76e4023 100644
--- a/docs/manual/common-usage.txt
+++ b/docs/manual/common-usage.txt
@@ -201,3 +201,50 @@ supported.
 --------------------------------
 GRAPH_OUT=svg make graph-depends
 --------------------------------
+
+Graphing the build duration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+[[graph-duration]]
+
+When the build of a system takes a long time, it is sometimes useful
+to be able to understand which packages are the longest to build, to
+see if anything can be done to speed up the build. In order to help
+such build time analysis, Buildroot collects the build time of each
+step of each package, and allows to generate graphs from these data.
+
+To generate the build time graph after a build, run:
+
+----------------
+make graph-build
+----------------
+
+This will generate a set of files in +output/graphs+ :
+
+* +build.hist-build.pdf+, an histogram of the build time for each
+  package, ordered in the build order.
+
+* +build.hist-duration.pdf+, an histogram of the build time for each
+  package, ordered by duration (longest first)
+
+* +build.hist-name.pdf+, an histogram of the build time for each
+  package, order by package name.
+
+* +build.pie-packages.pdf+, a pie chart of the build time per package
+
+* +build.pie-steps.pdf+, a pie chart of the global time spent in each
+  step of the packages build process.
+
+This +graph-build+ target requires the Python Matplotlib and Numpy
+libraries to be installed (+python-matplotlib+ and +python-numpy+ on
+most distributions), and also the +argparse+ module if you're using a
+Python version older than 2.7 (+python-argparse+ on most
+distributions).
+
+By default, the output format for the graph is PDF, but a different
+format can be selected using the +GRAPH_OUT+ environment variable. The
+only other format supported is PNG:
+
+----------------
+GRAPH_OUT=png make graph-build
+----------------
-- 
1.8.3.2

[Buildroot] [PATCH 06/13] docs/manual: add section about build time graphing

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  docs/manual/common-usage.txt | 47 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/docs/manual/common-usage.txt b/docs/manual/common-usage.txt
> index bef42c6..76e4023 100644
> --- a/docs/manual/common-usage.txt
> +++ b/docs/manual/common-usage.txt
> @@ -201,3 +201,50 @@ supported.
>  --------------------------------
>  GRAPH_OUT=svg make graph-depends
>  --------------------------------
> +
> +Graphing the build duration
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +[[graph-duration]]
> +
> +When the build of a system takes a long time, it is sometimes useful
> +to be able to understand which packages are the longest to build, to
> +see if anything can be done to speed up the build. In order to help
> +such build time analysis, Buildroot collects the build time of each
> +step of each package, and allows to generate graphs from these data.
> +
> +To generate the build time graph after a build, run:
> +
> +----------------
> +make graph-build
> +----------------
> +
> +This will generate a set of files in +output/graphs+ :
> +
> +* +build.hist-build.pdf+, an histogram of the build time for each
> +  package, ordered in the build order.
> +
> +* +build.hist-duration.pdf+, an histogram of the build time for each
> +  package, ordered by duration (longest first)
> +
> +* +build.hist-name.pdf+, an histogram of the build time for each
> +  package, order by package name.
> +
> +* +build.pie-packages.pdf+, a pie chart of the build time per package
> +
> +* +build.pie-steps.pdf+, a pie chart of the global time spent in each
> +  step of the packages build process.
> +
> +This +graph-build+ target requires the Python Matplotlib and Numpy
> +libraries to be installed (+python-matplotlib+ and +python-numpy+ on
> +most distributions), and also the +argparse+ module if you're using a
> +Python version older than 2.7 (+python-argparse+ on most
> +distributions).
> +
> +By default, the output format for the graph is PDF, but a different
> +format can be selected using the +GRAPH_OUT+ environment variable. The
> +only other format supported is PNG:
> +
> +----------------
> +GRAPH_OUT=png make graph-build
> +----------------

We also have GRAPH_ALT which sets an alternative colour-scheme for the
time graphs:
    GRAPH_ALT=y make graph-build

Which can be combined with GRAPH_OUT, of course.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 07/13] docs/manual: update informations about C library in internal backend

[Thomas Petazzoni]

Now that we have eglibc and glibc support in the internal backend, and
no longer marked as experimental, a little bit of rewording is
needed. It is no longer necessary to indicate that uClibc was
historically supported as the only C library, and that the glibc
support is experimental. We also update the rest of the description to
be less uClibc specific.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/configure.txt | 30 +++++++++++-------------------
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index 89df3d9..b566e8a 100644
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -68,12 +68,10 @@ The _internal toolchain backend_ is the backend where Buildroot builds
 by itself a cross-compilation toolchain, before building the userspace
 applications and libraries for your target embedded system.
 
-This backend is the historical backend of Buildroot, and has been
-limited for a long time to the usage of the
-http://www.uclibc.org[uClibc C library]. Support for the _eglibc_ C
-library has been added in 2013 and is at this point considered
-experimental. See the _External toolchain backend_ for another
-solution to use _glibc_ or _eglibc_.
+This backend supports several C libraries:
+http://www.uclibc.org[uClibc], the
+http://www.gnu.org/software/libc/libc.html[glibc] and
+http://www.eglibc.org[eglibc].
 
 Once you have selected this backend, a number of options appear. The
 most important ones allow to:
@@ -96,18 +94,7 @@ most important ones allow to:
    the C library might be using interfaces that are not provided by
    your Linux kernel.
 
- * Change the version and the configuration of the uClibc C library
-   (if uClibc is selected). The default options are usually
-   fine. However, if you really need to specifically customize the
-   configuration of your uClibc C library, you can pass a specific
-   configuration file here. Or alternatively, you can run the +make
-   uclibc-menuconfig+ command to get access to uClibc's configuration
-   interface. Note that all packages in Buildroot are tested against
-   the default uClibc configuration bundled in Buildroot: if you
-   deviate from this configuration by removing features from uClibc,
-   some packages may no longer build.
-
- * Change the version of the GCC compiler and binutils.
+ * Change the version of the GCC compiler, binutils and the C library.
 
  * Select a number of toolchain options (uClibc only): whether the
    toolchain should have largefile support (i.e support for files
@@ -118,7 +105,12 @@ most important ones allow to:
    libraries visible in Buildroot menus will change: many applications
    and libraries require certain toolchain options to be enabled. Most
    packages show a comment when a certain toolchain option is required
-   to be able to enable those packages.
+   to be able to enable those packages. If needed, you can further
+   refine the uClibc configuration by running +make
+   uclibc-menuconfig+. Note however that all packages in Buildroot are
+   tested against the default uClibc configuration bundled in
+   Buildroot: if you deviate from this configuration by removing
+   features from uClibc, some packages may no longer build.
 
 It is worth noting that whenever one of those options is modified,
 then the entire toolchain and system must be rebuilt. See
-- 
1.8.3.2

[Buildroot] [PATCH 07/13] docs/manual: update informations about C library in internal backend

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Now that we have eglibc and glibc support in the internal backend, and
> no longer marked as experimental, a little bit of rewording is
> needed. It is no longer necessary to indicate that uClibc was
> historically supported as the only C library, and that the glibc
> support is experimental. We also update the rest of the description to
> be less uClibc specific.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  docs/manual/configure.txt | 30 +++++++++++-------------------
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
> index 89df3d9..b566e8a 100644
> --- a/docs/manual/configure.txt
> +++ b/docs/manual/configure.txt
> @@ -68,12 +68,10 @@ The _internal toolchain backend_ is the backend where Buildroot builds
>  by itself a cross-compilation toolchain, before building the userspace
>  applications and libraries for your target embedded system.
>  
> -This backend is the historical backend of Buildroot, and has been
> -limited for a long time to the usage of the
> -http://www.uclibc.org[uClibc C library]. Support for the _eglibc_ C
> -library has been added in 2013 and is at this point considered
> -experimental. See the _External toolchain backend_ for another
> -solution to use _glibc_ or _eglibc_.
> +This backend supports several C libraries:
> +http://www.uclibc.org[uClibc], the

s/the//  since you don't do it for the other two.

> +http://www.gnu.org/software/libc/libc.html[glibc] and
> +http://www.eglibc.org[eglibc].
>  
>  Once you have selected this backend, a number of options appear. The
>  most important ones allow to:
> @@ -96,18 +94,7 @@ most important ones allow to:
>     the C library might be using interfaces that are not provided by
>     your Linux kernel.

Unrelated to your patch, but what about:
    [...] the C library might be using interfaces, or exposing thos
    interfaces to applications, that are not provided by the running
    Linux kernel.

> - * Change the version and the configuration of the uClibc C library
> -   (if uClibc is selected). The default options are usually
> -   fine. However, if you really need to specifically customize the
> -   configuration of your uClibc C library, you can pass a specific
> -   configuration file here. Or alternatively, you can run the +make
> -   uclibc-menuconfig+ command to get access to uClibc's configuration
> -   interface. Note that all packages in Buildroot are tested against
> -   the default uClibc configuration bundled in Buildroot: if you
> -   deviate from this configuration by removing features from uClibc,
> -   some packages may no longer build.
> -
> - * Change the version of the GCC compiler and binutils.
> + * Change the version of the GCC compiler, binutils and the C library.
>  
>   * Select a number of toolchain options (uClibc only): whether the
>     toolchain should have largefile support (i.e support for files
> @@ -118,7 +105,12 @@ most important ones allow to:
>     libraries visible in Buildroot menus will change: many applications
>     and libraries require certain toolchain options to be enabled. Most
>     packages show a comment when a certain toolchain option is required
> -   to be able to enable those packages.
> +   to be able to enable those packages. If needed, you can further
> +   refine the uClibc configuration by running +make
> +   uclibc-menuconfig+. Note however that all packages in Buildroot are
> +   tested against the default uClibc configuration bundled in
> +   Buildroot: if you deviate from this configuration by removing
> +   features from uClibc, some packages may no longer build.
>  
>  It is worth noting that whenever one of those options is modified,
>  then the entire toolchain and system must be rebuilt. See

Otherwise, looks good.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 08/13] docs/manual: update external toolchain examples

[Thomas Petazzoni]

Replace ADI by Analog Devices, which is clearer for most people, and
remove the Xilinx external toolchains since we have deprecated them.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/configure.txt | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index b566e8a..a6afafb 100644
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -138,10 +138,9 @@ http://www.linaro.org[Linaro] for ARM,
 http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/[Sourcery
 CodeBench] for ARM, x86, x86-64, PowerPC, MIPS and SuperH,
 https://blackfin.uclinux.org/gf/project/toolchain[Blackfin toolchains
-from ADI], http://git.xilinx.com/[Xilinx toolchains for Microblaze],
-etc.) and is capable of downloading them automatically, or it can be
-pointed to a custom toolchain, either available for download or
-installed locally.
+from Analog Devices], etc.) and is capable of downloading them
+automatically, or it can be pointed to a custom toolchain, either
+available for download or installed locally.
 
 Then, you have three solutions to use an external toolchain:
 
-- 
1.8.3.2

[Buildroot] [PATCH 08/13] docs/manual: update external toolchain examples

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Replace ADI by Analog Devices, which is clearer for most people, and
> remove the Xilinx external toolchains since we have deprecated them.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  docs/manual/configure.txt | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
> index b566e8a..a6afafb 100644
> --- a/docs/manual/configure.txt
> +++ b/docs/manual/configure.txt
> @@ -138,10 +138,9 @@ http://www.linaro.org[Linaro] for ARM,
>  http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/[Sourcery
>  CodeBench] for ARM, x86, x86-64, PowerPC, MIPS and SuperH,
>  https://blackfin.uclinux.org/gf/project/toolchain[Blackfin toolchains
> -from ADI], http://git.xilinx.com/[Xilinx toolchains for Microblaze],
> -etc.) and is capable of downloading them automatically, or it can be
> -pointed to a custom toolchain, either available for download or
> -installed locally.
> +from Analog Devices], etc.) and is capable of downloading them
> +automatically, or it can be pointed to a custom toolchain, either
> +available for download or installed locally.
>  
>  Then, you have three solutions to use an external toolchain:
>  
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 09/13] docs/manual: mention that custom toolchains is also useful for BR toolchains

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/configure.txt | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index a6afafb..42d84fe 100644
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -159,14 +159,14 @@ Then, you have three solutions to use an external toolchain:
   toolchain.
 
 * Use a completely custom external toolchain. This is particularly
-  useful for toolchains generated using crosstool-NG. To do this,
-  select the +Custom toolchain+ solution in the +Toolchain+ list. You
-  need to fill the +Toolchain path+, +Toolchain prefix+ and +External
-  toolchain C library+ options. Then, you have to tell Buildroot what
-  your external toolchain supports. If your external toolchain uses
-  the 'glibc' library, you only have to tell whether your toolchain
-  supports C\+\+ or not and whether it has built-in RPC support. If
-  your external toolchain uses the 'uClibc'
+  useful for toolchains generated using crosstool-NG or with Buildroot
+  itself. To do this, select the +Custom toolchain+ solution in the
+  +Toolchain+ list. You need to fill the +Toolchain path+, +Toolchain
+  prefix+ and +External toolchain C library+ options. Then, you have
+  to tell Buildroot what your external toolchain supports. If your
+  external toolchain uses the 'glibc' library, you only have to tell
+  whether your toolchain supports C\+\+ or not and whether it has
+  built-in RPC support. If your external toolchain uses the 'uClibc'
   library, then you have to tell Buildroot if it supports largefile,
   IPv6, RPC, wide-char, locale, program invocation, threads and
   C++. At the beginning of the execution, Buildroot will tell you if
-- 
1.8.3.2

[Buildroot] [PATCH 09/13] docs/manual: mention that custom toolchains is also useful for BR toolchains

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  docs/manual/configure.txt | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
> index a6afafb..42d84fe 100644
> --- a/docs/manual/configure.txt
> +++ b/docs/manual/configure.txt
> @@ -159,14 +159,14 @@ Then, you have three solutions to use an external toolchain:
>    toolchain.
>  
>  * Use a completely custom external toolchain. This is particularly
> -  useful for toolchains generated using crosstool-NG. To do this,
> -  select the +Custom toolchain+ solution in the +Toolchain+ list. You
> -  need to fill the +Toolchain path+, +Toolchain prefix+ and +External
> -  toolchain C library+ options. Then, you have to tell Buildroot what
> -  your external toolchain supports. If your external toolchain uses
> -  the 'glibc' library, you only have to tell whether your toolchain
> -  supports C\+\+ or not and whether it has built-in RPC support. If
> -  your external toolchain uses the 'uClibc'
> +  useful for toolchains generated using crosstool-NG or with Buildroot
> +  itself. To do this, select the +Custom toolchain+ solution in the
> +  +Toolchain+ list. You need to fill the +Toolchain path+, +Toolchain
> +  prefix+ and +External toolchain C library+ options. Then, you have
> +  to tell Buildroot what your external toolchain supports. If your
> +  external toolchain uses the 'glibc' library, you only have to tell
> +  whether your toolchain supports C\+\+ or not and whether it has
> +  built-in RPC support. If your external toolchain uses the 'uClibc'
>    library, then you have to tell Buildroot if it supports largefile,
>    IPv6, RPC, wide-char, locale, program invocation, threads and
>    C++. At the beginning of the execution, Buildroot will tell you if
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 10/13] docs/manual: rephrase paragraph about unsupported external toolchains

[Thomas Petazzoni]

The ELDK now relies on Yocto, so it no longer has the funky
non-standard way of doing multilib. Also, we didn't mention that Yocto
toolchains/SDK are not suitable for usage with Buildroot. Therefore,
this commit rewords this part of the documentation to explain that
Yocto/OpenEmbedded SDKs cannot be used as external toolchains in
Buildroot, and why.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/configure.txt | 24 +++++++-----------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/docs/manual/configure.txt b/docs/manual/configure.txt
index 42d84fe..9a12440 100644
--- a/docs/manual/configure.txt
+++ b/docs/manual/configure.txt
@@ -179,23 +179,13 @@ Buildroot itself. In general, all toolchains that support the
 'sysroot' feature should work. If not, do not hesitate to contact the
 developers.
 
-We do not support toolchains from the
-http://www.denx.de/wiki/DULG/ELDK[ELDK] of Denx, for two reasons:
-
-* The ELDK does not contain a pure toolchain (i.e just the compiler,
-  binutils, the C and C++ libraries), but a toolchain that comes with
-  a very large set of pre-compiled libraries and programs. Therefore,
-  Buildroot cannot import the 'sysroot' of the toolchain, as it would
-  contain hundreds of megabytes of pre-compiled libraries that are
-  normally built by Buildroot.
-
-* The ELDK toolchains have a completely non-standard custom mechanism
-  to handle multiple library variants. Instead of using the standard
-  GCC 'multilib' mechanism, the ARM ELDK uses different symbolic links
-  to the compiler to differentiate between library variants (for ARM
-  soft-float and ARM VFP), and the PowerPC ELDK compiler uses a
-  +CROSS_COMPILE+ environment variable. This non-standard behaviour
-  makes it difficult to support ELDK in Buildroot.
+We do not support toolchains or SDK generated by OpenEmbedded or
+Yocto, because these toolchains are not pure toolchains (i.e just the
+compiler, binutils, the C and C++ libraries). Instead these toolchains
+come with a very large set of pre-compiled libraries and
+programs. Therefore, Buildroot cannot import the 'sysroot' of the
+toolchain, as it would contain hundreds of megabytes of pre-compiled
+libraries that are normally built by Buildroot.
 
 We also do not support using the distribution toolchain (i.e the
 gcc/binutils/C library installed by your distribution) as the
-- 
1.8.3.2

[Buildroot] [PATCH 11/13] docs/manual: refresh informations about *-menuconfig targets

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/make-tips.txt | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/docs/manual/make-tips.txt b/docs/manual/make-tips.txt
index 0159ffe..faf59f2 100644
--- a/docs/manual/make-tips.txt
+++ b/docs/manual/make-tips.txt
@@ -32,10 +32,12 @@ The result of the search shows the help message of the matching items.
 Not all targets are always available,
 some settings in the +.config+ file may hide some targets:
 
+* +busybox-menuconfig+ and +busybox-savedefconfig+ ony work when
+  +busybox+ is enabled;
 * +linux-menuconfig+ and +linux-savedefconfig+ only work when
   +linux+ is enabled;
-* +uclibc-menuconfig+ is only available when the
-  Buildroot internal toolchain backend is used;
+* +uclibc-menuconfig+ is only available when the uClibc C library is
+  selected in the internal toolchain backend;
 * +barebox-menuconfig+ and +barebox-savedefconfig+ only work when the
   +barebox+ bootloader is enabled.
 
-- 
1.8.3.2

[Buildroot] [PATCH 11/13] docs/manual: refresh informations about *-menuconfig targets

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  docs/manual/make-tips.txt | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/manual/make-tips.txt b/docs/manual/make-tips.txt
> index 0159ffe..faf59f2 100644
> --- a/docs/manual/make-tips.txt
> +++ b/docs/manual/make-tips.txt
> @@ -32,10 +32,12 @@ The result of the search shows the help message of the matching items.
>  Not all targets are always available,
>  some settings in the +.config+ file may hide some targets:
>  
> +* +busybox-menuconfig+ and +busybox-savedefconfig+ ony work when
> +  +busybox+ is enabled;
>  * +linux-menuconfig+ and +linux-savedefconfig+ only work when
>    +linux+ is enabled;
> -* +uclibc-menuconfig+ is only available when the
> -  Buildroot internal toolchain backend is used;
> +* +uclibc-menuconfig+ is only available when the uClibc C library is
> +  selected in the internal toolchain backend;
>  * +barebox-menuconfig+ and +barebox-savedefconfig+ only work when the
>    +barebox+ bootloader is enabled.
>  
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 12/13] docs/manual: document the usage of <pkg>_OVERRIDE_SRCDIR

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/advanced.txt                    |  2 +
 docs/manual/using-buildroot-development.txt | 84 +++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)
 create mode 100644 docs/manual/using-buildroot-development.txt

diff --git a/docs/manual/advanced.txt b/docs/manual/advanced.txt
index 764b71a..fb337f5 100644
--- a/docs/manual/advanced.txt
+++ b/docs/manual/advanced.txt
@@ -11,3 +11,5 @@ include::ccache-support.txt[]
 include::download-location.txt[]
 
 include::package-make-target.txt[]
+
+include::using-buildroot-development.txt[]
diff --git a/docs/manual/using-buildroot-development.txt b/docs/manual/using-buildroot-development.txt
new file mode 100644
index 0000000..3267302
--- /dev/null
+++ b/docs/manual/using-buildroot-development.txt
@@ -0,0 +1,84 @@
+// -*- mode:doc; -*-
+// vim: set syntax=asciidoc:
+
+Using Buildroot during development
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The normal operation of Buildroot is to download a tarball, extract
+it, configure, compile and install the software component found inside
+this tarball. The source code is extracted in
++output/build/<package>-<name>+, which is a temporary directory:
+whenever +make clean+ is used, this directory is entirely removed, and
+re-recreated at the next +make+ invocation. Even when a Git or
+Subversion repository is used as the input for the package source
+code, Buildroot creates a tarball out of it, and then behaves as it
+does normally with tarballs.
+
+This behavior is well-suited when Buildroot is used mainly as an
+integration tool, to build and integrate all the components of an
+embedded Linux system. However, if one uses Buildroot during the
+development of certain components of the system, this behavior is not
+very convenient: one would instead like to make a small change to the
+source code of one package, and be able to quickly rebuild the system
+with Buildroot.
+
+Making changes directly in +output/build/<package>-<name>+ is not
+appropriate solution, because this directory is removed on +make
+clean+.
+
+Therefore, Buildroot provides a specific mechanism for this use case:
+the +<pkg>_OVERRIDE_SRCDIR+ mechanism. Buildroot reads an _override_
+file, which allows the user to tell Buildroot the location of the
+source for certain packages. By default this _override_ file is named
++local.mk+ and located in the top directory of the Buildroot source
+tree, but a different location can be specified through the
++BR2_PACKAGE_OVERRIDE_FILE+ configuration option.
+
+In this _override_ file, Buildroot expects to find lines of the form:
+
+------------------
+<pkg1>_OVERRIDE_SRCDIR = /path/to/pkg1/sources
+<pkg2>_OVERRIDE_SRCDIR = /path/to/pkg2/sources
+------------------
+
+For example:
+
+------------------
+LINUX_OVERRIDE_SRCDIR = /home/bob/linux/
+BUSYBOX_OVERRIDE_SRCDIR = /home/bob/busybox/
+------------------
+
+When Buildroot finds that for a given package, an
++<pkg>_OVERRIDE_SRCDIR+ has been defined, it will no longer attempt to
+download, extract and patch the package. Instead, it will directly use
+the source code available in in the specified directory and +make
+clean+ will not touch this directory. This allows to point Buildroot
+to your own directories, that can be managed by Git, Subversion, or
+any other version control system. To achieve this, Buildroot will use
+_rsync_ to copy the source code of the component from the specified
++<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom/+.
+
+This mechanism is best used in conjuction with the +make
+<pkg>-rebuild+ and +make <pkg>-reconfigure+ targets. A +make
+<pkg>-rebuild all+ sequence will _rsync_ the source code from
++<pkg>_OVERRIDE_SRCDIR+ to +output/build/<package>-custom+ (thanks to
+_rsync_, only the modified files are copied), and restart the build
+process of just this package.
+
+In the example of the +linux+ package above, the developer can then
+make a source code change in +/home/bob/linux+ and then run:
+
+-----------------------
+make linux-rebuild all
+-----------------------
+
+and in a matter of seconds gets the updated Linux kernel image in
++output/images+. Similarly, a change can be made to the Busybox source
+code in +/home/bob/busybox+, and after:
+
+-----------------------
+make busybox-rebuild all
+-----------------------
+
+the root filesystem image in +output/images+ contains the updated
+Busybox.
-- 
1.8.3.2

[Buildroot] [PATCH 12/13] docs/manual: document the usage of <pkg>_OVERRIDE_SRCDIR

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  docs/manual/advanced.txt                    |  2 +
>  docs/manual/using-buildroot-development.txt | 84 +++++++++++++++++++++++++++++
>  2 files changed, 86 insertions(+)
>  create mode 100644 docs/manual/using-buildroot-development.txt
> 
> diff --git a/docs/manual/advanced.txt b/docs/manual/advanced.txt
> index 764b71a..fb337f5 100644
> --- a/docs/manual/advanced.txt
> +++ b/docs/manual/advanced.txt
> @@ -11,3 +11,5 @@ include::ccache-support.txt[]
>  include::download-location.txt[]
>  
>  include::package-make-target.txt[]
> +
> +include::using-buildroot-development.txt[]
> diff --git a/docs/manual/using-buildroot-development.txt b/docs/manual/using-buildroot-development.txt
> new file mode 100644
> index 0000000..3267302
> --- /dev/null
> +++ b/docs/manual/using-buildroot-development.txt
> @@ -0,0 +1,84 @@
> +// -*- mode:doc; -*-
> +// vim: set syntax=asciidoc:
> +
> +Using Buildroot during development
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The normal operation of Buildroot is to download a tarball, extract
> +it, configure, compile and install the software component found inside
> +this tarball. The source code is extracted in
> ++output/build/<package>-<name>+, which is a temporary directory:

output/build/<package>-<version>

> +whenever +make clean+ is used, this directory is entirely removed, and
> +re-recreated at the next +make+ invocation. Even when a Git or
> +Subversion repository is used as the input for the package source
> +code, Buildroot creates a tarball out of it, and then behaves as it
> +does normally with tarballs.

normally does

> +This behavior is well-suited when Buildroot is used mainly as an
> +integration tool, to build and integrate all the components of an
> +embedded Linux system. However, if one uses Buildroot during the
> +development of certain components of the system, this behavior is not
> +very convenient: one would instead like to make a small change to the
> +source code of one package, and be able to quickly rebuild the system
> +with Buildroot.
> +
> +Making changes directly in +output/build/<package>-<name>+ is not

output/build/<package>-<version>

> +appropriate solution, because this directory is removed on +make
> +clean+.
> +
> +Therefore, Buildroot provides a specific mechanism for this use case:
> +the +<pkg>_OVERRIDE_SRCDIR+ mechanism. Buildroot reads an _override_
> +file, which allows the user to tell Buildroot the location of the
> +source for certain packages. By default this _override_ file is named
> ++local.mk+ and located in the top directory of the Buildroot source
> +tree,

Wrong, now it is locate in $(CONFIG_DIR), that is, the directory where
we have the .config file, since:
    b1e514d Config: default BR2_PACKAGE_OVERRIDE_FILE to $(CONFIG_DIR)/local.mk

This is Buildroot's top dir when building in-tree, and for out-of-tree
builds, it's in $(O).

[--SNIP--]

Otherwise, LGTM.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 12/13] docs/manual: document the usage of <pkg>_OVERRIDE_SRCDIR

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 >> +appropriate solution, because this directory is removed on +make
 >> +clean+.
 >> +
 >> +Therefore, Buildroot provides a specific mechanism for this use case:
 >> +the +<pkg>_OVERRIDE_SRCDIR+ mechanism. Buildroot reads an _override_
 >> +file, which allows the user to tell Buildroot the location of the
 >> +source for certain packages. By default this _override_ file is named
 >> ++local.mk+ and located in the top directory of the Buildroot source
 >> +tree,

 > Wrong, now it is locate in $(CONFIG_DIR), that is, the directory where
 > we have the .config file, since:
 >     b1e514d Config: default BR2_PACKAGE_OVERRIDE_FILE to $(CONFIG_DIR)/local.mk

 > This is Buildroot's top dir when building in-tree, and for out-of-tree
 > builds, it's in $(O).

True, but that commit is only in next, and I imho think this series
belongs on master, so I'll leave it for now.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 12/13] docs/manual: document the usage of <pkg>_OVERRIDE_SRCDIR

[Yann E. MORIN]

On 2014-02-23 22:29 +0100, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
> Hi,
> 
>  >> +appropriate solution, because this directory is removed on +make
>  >> +clean+.
>  >> +
>  >> +Therefore, Buildroot provides a specific mechanism for this use case:
>  >> +the +<pkg>_OVERRIDE_SRCDIR+ mechanism. Buildroot reads an _override_
>  >> +file, which allows the user to tell Buildroot the location of the
>  >> +source for certain packages. By default this _override_ file is named
>  >> ++local.mk+ and located in the top directory of the Buildroot source
>  >> +tree,
> 
>  > Wrong, now it is locate in $(CONFIG_DIR), that is, the directory where
>  > we have the .config file, since:
>  >     b1e514d Config: default BR2_PACKAGE_OVERRIDE_FILE to $(CONFIG_DIR)/local.mk
> 
>  > This is Buildroot's top dir when building in-tree, and for out-of-tree
>  > builds, it's in $(O).
> 
> True, but that commit is only in next, and I imho think this series
> belongs on master, so I'll leave it for now.

Right! In fact, I was looking at my tree, which has it. It's eda3d0e on
-next.

And I agree, this series belongs to master. We'll just have to remember
it at merge time.

Sorry for the disruption.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 13/13] docs/manual: mention the per-package graph-depends target

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 docs/manual/package-make-target.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/manual/package-make-target.txt b/docs/manual/package-make-target.txt
index 9eefe68..bd514f4 100644
--- a/docs/manual/package-make-target.txt
+++ b/docs/manual/package-make-target.txt
@@ -63,6 +63,11 @@ Additionally, there are some other useful make targets:
 | +show-depends+    | Displays the dependencies required to build the
 package
 
+| +graph-depends+   | Generate a dependency graph of the package, in the
+context of the current Buildroot configuration. See
+xref:graph-depends[this section] for more details about dependency
+graphs.
+
 | +dirclean+        | Remove the whole package build directory
 
 | +rebuild+         | Re-run the compilation commands - this only makes
-- 
1.8.3.2

[Buildroot] [PATCH 13/13] docs/manual: mention the per-package graph-depends target

[Yann E. MORIN]

Thomas, All,

On 2014-02-23 16:04 +0100, Thomas Petazzoni spake thusly:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  docs/manual/package-make-target.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/docs/manual/package-make-target.txt b/docs/manual/package-make-target.txt
> index 9eefe68..bd514f4 100644
> --- a/docs/manual/package-make-target.txt
> +++ b/docs/manual/package-make-target.txt
> @@ -63,6 +63,11 @@ Additionally, there are some other useful make targets:
>  | +show-depends+    | Displays the dependencies required to build the
>  package
>  
> +| +graph-depends+   | Generate a dependency graph of the package, in the
> +context of the current Buildroot configuration. See
> +xref:graph-depends[this section] for more details about dependency
> +graphs.
> +
>  | +dirclean+        | Remove the whole package build directory
>  
>  | +rebuild+         | Re-run the compilation commands - this only makes
> -- 
> 1.8.3.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 00/13] Documentation updates and improvements

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > Here is a set of documentation updates and improvements, about
 > toolchains, package infrastructures, dependency and build-time
 > graphing, and also finally a documentation about
 > <pkg>_OVERRIDE_SRCDIR.

 > Thomas

 > Thomas Petazzoni (13):
 >   docs/manual: toolchain packages no longer use custom makefiles
 >   docs/manual: rephrase part about rebuilding packages
 >   docs/manual: rephrase and expand part on when a full rebuild is
 >     necessary
 >   docs/manual: reference Python and Lua infras from the list of package
 >     infrastructures
 >   docs/manual: add section about dependency graphs
 >   docs/manual: add section about build time graphing
 >   docs/manual: update informations about C library in internal backend
 >   docs/manual: update external toolchain examples
 >   docs/manual: mention that custom toolchains is also useful for BR
 >     toolchains
 >   docs/manual: rephrase paragraph about unsupported external toolchains
 >   docs/manual: refresh informations about *-menuconfig targets
 >   docs/manual: document the usage of <pkg>_OVERRIDE_SRCDIR
 >   docs/manual: mention the per-package graph-depends target

Committed series with the minor changes suggested by Yann, thanks.

-- 
Bye, Peter Korsgaard