From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] buildroot:download: Add option to download SVN or GIT repository with version control information.
Date: Mon, 20 Dec 2010 15:05:04 +0100 [thread overview]
Message-ID: <20101220150504.4dcf2e18@surf> (raw)
In-Reply-To: <1292591501.6496.58.camel@dubciaranr0.verifone.com>
Hello,
On Fri, 17 Dec 2010 13:11:41 +0000
Quotient Remainder <quotientvremainder@gmail.com> wrote:
> There are many great features in Buildroot and one of them is that you
> can just give it a defconfig and off it goes to retrieve all the
> required components. It would be a pity to leave this out of the
> "working tree" support structure.
> I had the idea (not implemented yet) that Buildroot should try to check
> out $(PKG)_DL_VERSION and if it fails, get an update from upstream and
> try to checkout again, failing only at this point. Of course changes to
> the working copy would have to be cautious so that changes are not
> overwritten unintentionally. OK the thinking is a bit GIT-centric but
> can be expanded to other VCS also. Doesn't everything start by
> supporting a limited set before aiming for world domination...
Sorry, I didn't follow you here. Could you elaborate ?
> The way I see it Buildroot is used both by developers ("I want to change
> source code") and by those who just want a repeatable way to make a
> bootable system ("just give me a burnable image"). It would be ideal if
> the same system could be used by both camps.
> Keeping the source code outside BUILD_DIR through your OVERRIDE_SRC_DIR
> seems like a big step towards this. "make clean" just deletes
> BUILD_DIR, not the OVERRIDE dirs.
Yes, that's the plan.
> > * It is only valid for components for which sourcing from git/svn is
> > done.
>
> But didn't someone post a BZR patch recently and can't it be extended to
> any other VCS with an equivalent DOWNLOAD_$(VCS) macro? Or am I missing
> your point?
What I meant here is that components that are fetched from tarballs are
not being handled by Sonic's approach.
> I did, but it's really dirty, invloving a cautious rsync at build-time
> between the working copy and BUILD_DIR. Your OVERRIDE_DIR is vastly
> superior and glaringly obvious now that it's mentioned.
> One nice feature of my approach was that it needed no modifications in
> the package makefiles, if a VCS method was specified (in a file similar
> to your "local.mk") the location and variables there override the
> package makefile.
The approach I propose also shouldn't require any modification to the
package makefiles. It should only require modifications at the package
infrastructure level.
Regards,
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:[~2010-12-20 14:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-16 9:49 [Buildroot] [PATCH v2] buildroot:download: Add option to download SVN or GIT repository with version control information Sonic Zhang
2010-12-16 9:49 ` [Buildroot] [PATCH v2] buildroot:linux: Add options to checkout Linux kernel source from SVN or GIT repository Sonic Zhang
2010-12-17 10:40 ` Thomas Petazzoni
2010-12-16 14:19 ` [Buildroot] [PATCH v2] buildroot:download: Add option to download SVN or GIT repository with version control information Quotient Remainder
2010-12-17 2:44 ` Sonic Zhang
2010-12-16 21:22 ` Lionel Landwerlin
2010-12-17 2:52 ` Sonic Zhang
2010-12-17 10:34 ` Thomas Petazzoni
2010-12-17 13:11 ` Quotient Remainder
2010-12-20 14:05 ` Thomas Petazzoni [this message]
2010-12-20 16:04 ` Quotient Remainder
2010-12-20 16:08 ` Thomas Petazzoni
2010-12-20 16:37 ` Quotient Remainder
2010-12-20 16:47 ` Thomas Petazzoni
2010-12-20 9:11 ` Sonic Zhang
2010-12-20 11:37 ` Daniel Nyström
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=20101220150504.4dcf2e18@surf \
--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.