mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Juergen Borleis <jbe@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: [ptxdist] [PATCH 1/4] doc: BUILDTIME versus RUNTIME
Date: Fri, 22 Feb 2019 11:03:00 +0100	[thread overview]
Message-ID: <20190222100303.16360-1-jbe@pengutronix.de> (raw)

Describe the difference of some detailed dependency descriptions in
Kconfig menufiles.

Signed-off-by: Juergen Borleis <jbe@pengutronix.de>
---
 doc/daily_work.inc | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 doc/dev_manual.rst |  5 +++++
 2 files changed, 63 insertions(+)

diff --git a/doc/daily_work.inc b/doc/daily_work.inc
index 5708903db..e4260e448 100644
--- a/doc/daily_work.inc
+++ b/doc/daily_work.inc
@@ -1297,3 +1297,61 @@ non-interactive user, e.g. a different application.
    should use the **LGPL license for both parts** from the beginning. Else
    you may cannot move source code in such a way, because it would require a
    license change for this specific piece of source code (to be pedantic!).
+
+.. _external_dependencies_variants:
+
+Controling Package Dependencies in more Detail
+----------------------------------------------
+
+In section :ref:`external_dependencies` a simple method is shown how to define
+an external package dependency a particular package can have in order to build
+it.
+
+Implicit Dependencies
+~~~~~~~~~~~~~~~~~~~~~
+
+For the simple dependency definition PTXdist adds internally a dependency
+to the *install* stage of the defined external dependency (or to a different
+package to use PTXdist glossary).
+
+We must keep this in mind, because there are packages out there, which don't
+install anything in their *install* stage. They install something in their
+*targetinstall* stage instead. In this case even if the dependency is defined
+like shown in :ref:`external_dependencies`, building the particular package may
+fail depending on the build order.
+
+To avoid this, an explicit ``make`` style dependency must be added to the rule
+file. If the *compile* stage of package ``foo`` has a dependency to package
+``bar``'s *targetinstall* stage just add the following lines to your rule file:
+
+.. code-block:: make
+
+   $(STATEDIR)/foo.compile: $(STATEDIR)/bar.targetinstall
+
+Build-Time only Dependency
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes packages have a compile-time dependency to a different package, but
+can live without its content at run-time. An example can be a static library
+which is linked at compile-time and not required as a separate package at
+run-time. Another example is making use of this detailed dependency can make
+developer's life easier when using individual package lists for dedicated
+image files. Think about a development image and a production image which should
+be built at the same time but should contain a different packages list each
+(refer :ref:`multi_image_individual_root_filesystems` for details).
+
+Marking a menu file based dependency with ``if BUILDTIME`` limits the dependency
+to compile-time only. In this case its possible to have the package in one
+image's list, but not its dependency.
+
+Run-Time only Dependency
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The other way round is ``if RUNTIME``. This forces the dependency package is
+part of the final image as well, but PTXdist can improve its build-time job by
+reordering package's build.
+A use case for this run-time dependency can be a package which just installs a
+shell script. This shell script makes use of some shell commands which must be
+present at run-time and thus depends on a package which provides these shell
+commands. But these shell commands are not required to build the shell script
+itself. In this case PTXdist can build both packages independently.
diff --git a/doc/dev_manual.rst b/doc/dev_manual.rst
index a14e64b0f..f0c2e00ee 100644
--- a/doc/dev_manual.rst
+++ b/doc/dev_manual.rst
@@ -992,6 +992,8 @@ as expected:
 Whenever we change a *FOO* related menu entry, PTXdist should detect it
 and re-build the package when a new build is started.
 
+.. _external_dependencies:
+
 Managing External Compile Time Dependencies
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -1035,6 +1037,9 @@ file looks like:
 
 PTXdist now builds the *zlib* first and our new package thereafter.
 
+Refer :ref:`external_dependencies_variants` for more specific dependency
+description.
+
 Managing External Compile Time Dependencies on Demand
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-- 
2.11.0


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

             reply	other threads:[~2019-02-22 10:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 10:03 Juergen Borleis [this message]
2019-02-22 10:03 ` [ptxdist] [PATCH 2/4] doc: follow 'proselint' and improve the text Juergen Borleis
2019-02-22 10:03 ` [ptxdist] [PATCH 3/4] doc: describe a strange behaviour and its solution Juergen Borleis
2019-02-22 10:03 ` [ptxdist] [PATCH 4/4] doc: fix missing step to setup a Python virtualenv Juergen Borleis
2019-02-22 11:37   ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190222100303.16360-1-jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox