All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antti Kantee <pooka@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: wei.liu2@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH] OSSTEST: introduce a raisin build test
Date: Wed, 06 May 2015 16:11:14 +0000	[thread overview]
Message-ID: <554A3D22.3010107@iki.fi> (raw)
In-Reply-To: <alpine.DEB.2.02.1505061156200.2640@kaball.uk.xensource.com>

On 06/05/15 11:03, Stefano Stabellini wrote:
> On Wed, 6 May 2015, Ian Jackson wrote:
>> Stefano Stabellini writes ("Re: [PATCH] OSSTEST: introduce a raisin build test"):
>>> That's fine as there is no hidden git cloning with raisin. All the trees
>>> are specified explicitly in the config file.
>>
>> Is this a fundamental design principle ?
>>
>> The rump kernel build system uses git submodules, which are (very
>> annoying and) a kind of hidden git cloning, and it also has a
>> [psuedo-submodule a bit like xen.git wrt qemu et al.
>
> Oh dear lord.
>
> I am keeping not having hidden git cloning as a fundamental design
> principle and goal of the project. I haven't tried to integrated rump
> kernels into raisin yet, but as I told you IRL, I have been thinking of
> writing the build system in a way that the git cloning is done by
> raisin, even for rump kernels.

Well, these days it pulls the submodules in if they're not already 
present.  If you pull them in manually before running the build script, 
no hidden cloning happens.  Given that you want to pull them in manually 
anyway, I don't see a problem.

It's actually more of a historic remnant from times when checking out 
the necessary sources was a non-trivial operation involving separate 
user/kernel repositories and copying/patching sources all around.  I 
think it was fixed over a year ago.

I guess I could remove the "git submodule update" detection/execution 
from the build script entirely.  It's sort of illogical that you don't 
have to execute it after you clone initially but realistically speaking 
have to execute it after every pull -- makes us look like drug dealers.

      reply	other threads:[~2015-05-06 16:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 15:46 [PATCH] OSSTEST: introduce a raisin build test Stefano Stabellini
2015-05-05 11:57 ` Ian Campbell
2015-05-05 14:59   ` Ian Jackson
2015-05-05 16:49     ` Stefano Stabellini
2015-05-05 17:17       ` Ian Jackson
2015-05-05 17:47         ` Stefano Stabellini
2015-05-06  8:41           ` Ian Campbell
2015-05-06 11:16             ` Stefano Stabellini
2015-05-06 11:45               ` Ian Campbell
2015-05-05 17:53   ` Stefano Stabellini
2015-05-06 10:09     ` Ian Jackson
2015-05-06 11:03       ` Stefano Stabellini
2015-05-06 16:11         ` Antti Kantee [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=554A3D22.3010107@iki.fi \
    --to=pooka@iki.fi \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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.