[OpenWrt-Devel] couple questions about downloading for a new build

Robert P. J. Day rpjday at crashcourse.ca
Thu Sep 11 09:12:03 EDT 2014

On Thu, 11 Sep 2014, Yousong Zhou wrote:

> On 11 September 2014 20:30, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
> >
> >   first, i created a local mirror with all the tarballs i
> > downloaded during an earlier build, and configured a new build to
> > use that, and i noticed that the download operation *copied* over
> > the tarballs into the dl/ directory. is there any reason that
> > symlinks aren't used, rather than doing actual copies? wouldn't
> > symlinks work just as well?
> I take mirrors as places where the build system will try to fetch
> those tarballs, into CONFIG_DOWNLOAD_FOLDER which defaults to
> $(TOPDIR)/dl/ which in my local tree is a symbolic link to the
> actually directory holding those tarballs.  It works quite well.

  i realize that's *one* way to do it, and it's how i did it
originally, but i chose instead to set up a single local mirror
directory that each build can "fetch" from into their personal dl/
directory, whereupon i noticed that fetching from that local mirror
really is doing a full copy, whereas it *seems* that just doing a
symlink would work just as well and not use up all that disk space.

  i'm just wondering why symlinks aren't used.

> >   also, i wondered if building the host tools would take advantage
> > of already-installed host tools that match the exact version that
> > openwrt needs. in my new build, the version of "patch" required is
> > ostensibly 2.7.1, which is precisely the version already installed
> > on my host, but it appears the patch-2.7.1.tar.xz tarball was
> > still copied (from the local mirror, admittedly) into the dl/
> > directory.
> IMHO, for a build system complex like OpenWrt, it's better to be
> self-contained and do things in a more predictable/controlled way.

  i agree, it was just the way i was reading the comment below that i
think confused me.

> >   i haven't followed the Makefile structures far enough yet to see
> > what should happen, but a comment in tools/Makefile reads:
> >
> > # in case there is no patch tool on the host we need to make patch
> > # tool a dependency for tools which have patches directory
> >
> > which *seems* to suggest that the build will look for patch already
> > installed on the host and take advantage of it if it's there.
> No, it tries to handle the case that some host tools needs to be
> patched (having patches/ directory) before getting compiled in which
> case those tools/XXX/compile needs to have a dependence on
> tools/patch/install.

  ok, i think i see what that comment means ... if any tool needs
patching, then patch is registered as a necessary host tool and it
*will* be downloaded and built, even if it already exists on the host,

  however, assuming i understand that, there are now two new things
that puzzle me. first, i selected CONFIG_CCACHE and, as i read it,
that would normally mean i would need the ccache utility to be
downloaded and built as a host tool (even if it's already installed,
yes?). but it's not. even though:


i see no ccache tarball in my dl/ direectory. ccache is, in fact,
installed on my build host, but i thought we just agreed that that
shouldn't make a difference. so what would force ccache to be
downloaded and built?

  finally, mtd-utils -- the recipe specifies both a version number and
git info in the Makefile:



  now, the first time i downloaded all the tools, git cloned the
mtd-utils repository, and created the tarball mtd-utils-1.4.5.tar.gz.
however, even though i added that to my local mirror directory, the
download uses a "git clone" every time. should it not look in my local
mirror, and notice that the tarball is there? or does that not apply
to source that is cloned from a git repo?



Robert P. J. Day                                 Ottawa, Ontario, CANADA

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list