From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] DL_TOOLS_DEPENDENCIES and PRIMARY_SITE
Date: Fri, 2 Mar 2012 10:37:47 +0100 [thread overview]
Message-ID: <20120302103747.7f8ef528@skate> (raw)
In-Reply-To: <CAAXf6LXfd_w5muFabHEFxYKgCFSsrsCCX0Cqibpfz0o7NZt1wQ@mail.gmail.com>
Hello,
Le Fri, 2 Mar 2012 10:16:53 +0100,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
> Suppose you have a PRIMARY_SITE set for direct retrieval of source
> tarballs instead of fetching them from the web, for example because
> you want a self-contained buildroot distribution to give to others.
>
> If you select a package that has git/svn/bzr/... as site method, then
> the dependencies system will check for the availability of the
> git/svn/bzr tools.
> In case all tarballs are present on the PRIMARY_SITE, this check is
> actually not needed and annoying, because you would have to e.g.
> install 'git' even though it will never be used.
Hum, right.
> Some suggested solutions:
> 1. change support/dependencies/dependencies.sh to output a warning
> instead of an error for the DL_TOOLS. If the tool cannot be found when
> used, the shell will throw an error.
>
> 2. when PRIMARY_SITE is set, don't fill DL_TOOLS at all (so don't
> check in support/dependencies), and let the shell handle a missing
> tool.
>
> 3. Don't check the DL_TOOLS in support/dependencies upfront, but
> rather in the DOWNLOAD function when you actually need a certain tool.
The problem with (2) is that PRIMARY_SITE is only a *preferred*
location for download. If that location does not contain the requested
tarball, then we fall back to the normal download method, and in that
case we would need git/bzr/svn/etc. Or we would need to change the
semantic of PRIMARY_SITE so that we *only* look at PRIMARY_SITE and do
not fall back on the normal download method (and therefore abort the
build if PRIMARY_SITE does not contain all the desired tarballs).
As per (1) and (3), for sure it would work, but I think having all the
dependencies errors upfront is really nice, because you can fix all of
them at the beginning of the build, and then you know that the build
will go on. There's nothing more annoying than starting a long build,
going away for a coffee/tea/orange-juice (because I don't drink
coffee/tea), then coming back to discover that the build has stopped 30
seconds after we left just because of a missing dependency.
Another option on your build servers is:
echo "#!/bin/sh" > /usr/bin/git && chmod +x /usr/bin/git
echo "#!/bin/sh" > /usr/bin/svn && chmod +x /usr/bin/svn
And go ? :-)
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-03-02 9:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 9:16 [Buildroot] DL_TOOLS_DEPENDENCIES and PRIMARY_SITE Thomas De Schampheleire
2012-03-02 9:37 ` Thomas Petazzoni [this message]
2012-03-02 9:55 ` Will Newton
2012-03-02 10:02 ` Thomas De Schampheleire
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=20120302103747.7f8ef528@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.