All of lore.kernel.org
 help / color / mirror / Atom feed
From: jfabernathy <jfabernathy@gmail.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: yocto@yoctoproject.org
Subject: Re: tar ball vs. git development questions
Date: Mon, 23 Jan 2012 07:51:26 -0500	[thread overview]
Message-ID: <4F1D57CE.2050807@gmail.com> (raw)
In-Reply-To: <4F1CB41A.301@mlbassoc.com>

On 01/22/2012 08:12 PM, Gary Thomas wrote:
> On 2012-01-22 13:19, James Abernathy wrote:
>> I have used both git and the tarball methods of bitbaking projects, 
>> all of them derivatives of the examples in the Yocto documentation. I 
>> was having issues using the local clone of
>> the Yocto kernel git repository this weekend. I had successfully done 
>> that before, but I was rebuilding the PC workstation, and getting 
>> everything setup and tested some of the
>> meta-intel BSPs to make sure I had everything right. Cloning the 
>> linux-yocto-3.0 repository was successful, but the bakes against it 
>> failed. I made sure I had poky-extras setup
>> right, but I still had problems. To isolate the problem, I changed to 
>> building with the tarballs and everything worked fine.
>>
>> So that got me thinking what are the differences between the 2 methods:
>>
>>   * I assume that if I use the tarball method, bitbake, using the 
>> recipes, pulls down files from the online repositories and puts those 
>> files into the centralized local download
>>     directory ($DL_DIR), allowing reuse instead of re-downloading 
>> each time. The content downloaded for linux-yocto-3.0 is exactly what 
>> would be pulled from the local repository if
>>     I used a local clone of the git repository for linux-yocto-3.0.
>>   * If my assumption above is correct, if I'm not modifying the 
>> source code of the kernel (only changing config parameters), then 
>> once you've run at least one build with the
>>     tarball method, the $DL_DIR directory contains all the files 
>> you'll need to build any image with linux-yocto-3.0. So there is no 
>> need to have a local clone of the kernel
>>     repository for speeding up development. Am I right?
>>   * If I have a successful creation of a bare clone of 
>> linux-yocto-3.0.git, how could builds of Edison packages be failing? 
>> That makes me concerned about using git and successfully
>>     repeating builds of stable branches like Edison.
>
> If you set BB_GENERATE_MIRROR_TARBALLS = "1" (e.g. in local.conf)
> then you'll get tarballs which hold the git repositories after
> download.  You can then reuse these (by sharing the DL_DIR or
> using a local mirror).  Does that help with the issue you're seeing?
>
I'm not sure it does.  I don't want poky to do more work.  I have my 
download directory, $DL_DIR, outside my build directory so I can keep it 
run to run, as mentioned in the comments in local.conf. I was trying to 
understand 2 basic questions:

1.  what could be causing build failures using a freshly created bare 
clone yesterday vs. using the poky-edison-6.0 tarball.  It would be 
scary if you could clone the linux-yocto-3.0 successfully one day and 
have it be used in a build successfully, but clone it another day and it 
not work.  I figured that bitbake/poky pulled the same information into 
DL_DIR regardless of whether you pulled from the bare clone locally or 
straight from the on-line repository.
2. I was trying to look at items to speed up build runs.  I thought that 
if the downloads in DL_DIR were reused if they existed, it would speed 
up a run. It seems to.  So the question is, after the first build, the 
files I need for linux-yocto-3.0 are in DL_DIR regardless of whether 
they came from the online repository or the local bare clone. right?

Jim A



  reply	other threads:[~2012-01-23 12:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-22 20:19 tar ball vs. git development questions James Abernathy
2012-01-23  1:12 ` Gary Thomas
2012-01-23 12:51   ` jfabernathy [this message]
2012-01-23 13:10     ` Gary Thomas
2012-01-23 14:01       ` Bruce Ashfield
2012-01-24 21:24         ` James Abernathy

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=4F1D57CE.2050807@gmail.com \
    --to=jfabernathy@gmail.com \
    --cc=gary@mlbassoc.com \
    --cc=yocto@yoctoproject.org \
    /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.