All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <list@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH/RFC] Download sources from Git (and more)
Date: Tue, 13 Jul 2010 22:14:18 +0200	[thread overview]
Message-ID: <4C3CC91A.1060502@lucaceresoli.net> (raw)
In-Reply-To: <1279032219.2887.78.camel@dubciaranr1.verifone.com>

Quotient Remainder wrote:
> Ar Luan, 2010-07-12 ag 23:30 +0200, scr?obh Luca Ceresoli:
>   
>> Hi,
>>
>> this patchset is a tentative generalization of the DOWNLOAD macro, as
>> recently discussed in mailing-list, in order to allow BR to obtain
>> package sources not only as tar files from http/ftp, but also using
>> other protocols.
>>
>> I borrowed some pieces of code from Quotient Remainder's patch, but this
>> approach is substiatially different.
>>
>> The feature list is short: I deliberately wanted to be minimalistic
>> but set up a clean infrastructure that can be extended later.
>>
>> Even though these patches are quite polished, please consider them as
>> a proposal for discussion. If there is general consensus about the way
>> I propose, I'll be glad to add a bit of user documentation as well.
>>
>> In the first two patches I prepare the ground by making the download
>> infrastructure more general. The DOWNLOAD function is replaced by a
>> per-package $(PKG)_DOWNLOAD, whose value is computed automatically
>> from the site URL but can be overridden. The good old wget system is
>> modified to fit in the new framework.
>>
>> In the third and fourth commit I add DOWNLOAD_GIT, which is relatively
>> straightforward given the whole infrastructure is already in place.
>> The place where the repository should be cloned might not be appreciated,
>> but I definitely think it should go in output/, as it is part of
>> buildroot's -well- output, not of the package "recipe".
>>
>> The last patch is surely *not* meant to be committed. It's just a
>> minimalistic example of a package downloaded via Git, and would be
>> replaced by user docs as stated above.
>>
>> Luca
>>     
>
> I personally quite like the approach here and think it's more flexible
> than the patch set from Maxime, but have two questions.
>
>  - Why not make the usual tarball in $(DL_DIR) with "git archive
> --format=tar ... | gzip > $(DL_DIR)/..." instead of the self-described
> "hack" of skipping the extraction step?  I suppose it's slightly faster
> since you avoid the compression and decompression time but that mightn't
> be too significant.  I just wonder if the skipping of this stage may
> have some side effects especially if packages have custom extraction
> steps.
>   
That would be very simple, and probably cleaner as you noted.
I think it's worth doing after all, since it would save download time for
example after `make clean`.
I'll code it as time permits.

>  - Do you see any way of making it possible to use the clone as the
> actual working copy used by buildroot?  That is, if I clone a repository
> (as opposed to archive) and then want to make changes, I can edit the
> source and build/test the change in-place (in output/build/package/) .
> As it stands with this patch set, I think it would be necessary to make
> a change in the source in $(PKG_NAME).git/, commit the change, note the
> new version, change the package version in package/Makefile to the same
> and make will then copy an entire snapshot to a new
> build-dir/pkg-newversion/.
>   
This would certainly be useful, but hard to couple with the current
buildroot structure, as Thomas pointed out in this thread. A discussion
would be needed before such a thing.

Luca

>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

      parent reply	other threads:[~2010-07-13 20:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 21:30 [Buildroot] [PATCH/RFC] Download sources from Git (and more) Luca Ceresoli
2010-07-12 21:30 ` [Buildroot] [PATCH 1/5] packages: pass the package name to the DOWNLOAD macro Luca Ceresoli
2010-07-12 21:30 ` [Buildroot] [PATCH 2/5] packages: allow different download protocols, with auto detection Luca Ceresoli
2010-07-12 21:42   ` Michael S. Zick
2010-07-12 21:30 ` [Buildroot] [PATCH 3/5] Unleash all of git's power: not only clones Luca Ceresoli
2010-07-12 21:30 ` [Buildroot] [PATCH 4/5] packages: add DOWNLOAD_GIT Luca Ceresoli
2010-07-12 21:30 ` [Buildroot] [PATCH 5/5] FOR TESTING ONLY: Add a GIT-downloaded test package Luca Ceresoli
2010-07-13 14:43 ` [Buildroot] [PATCH/RFC] Download sources from Git (and more) Quotient Remainder
2010-07-13 18:08   ` Thomas Petazzoni
2010-07-13 20:49     ` Luca Ceresoli
2010-07-14 12:28     ` Quotient Remainder
2010-07-13 20:14   ` Luca Ceresoli [this message]

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=4C3CC91A.1060502@lucaceresoli.net \
    --to=list@lucaceresoli.net \
    --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.