All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: [PATCH 3/3] osstest: add FreeBSD Xen build job
Date: Tue, 3 Jul 2018 18:10:35 +0200	[thread overview]
Message-ID: <20180703161035.hbf66zm3plw4ocps@mac.bytemobile.com> (raw)
In-Reply-To: <23355.38085.803261.551348@mariner.uk.xensource.com>

On Tue, Jul 03, 2018 at 04:22:45PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH 3/3] osstest: add FreeBSD Xen build job"):
> > To both the FreeBSD and the xen-unstable flights.
> > 
> > This is the runvar difference of a xen-unstable flight:
> 
> Just to clarify my thinking:
> 
> > +    # Create a Xen build job that's going to use the output from the first
> > +    # FreeBSD build job.
> 
> I think you do it like this so that on the freebsd branch, we use the
> new being-tested version of freebsd, and see if it breaks the Xen
> build.

Yes, that's the intention.

> > +    case "$xenbranch" in
> > +    xen-unstable) build_on_freebsd=true;;
> > +    *)            build_on_freebsd=false;;
> 
> I don't think this is right.  Why do we only want to do this with
> xen-unstable ?  If the problem is that you need "new enough" xen, then
> you need the version comparison case pattern used elsewhere, so that
> each new branch of Xen has this turned on.

Yes, you are right.

> > +      if [ x$arch = xamd64 ] && [ x$build_on_freebsd = xtrue ] ; then
> > +        job_create_build build-$arch$xsm_suffix-freebsd build-xen-freebsd    \
> > +          arch=$arch                                                         \
> > +          enable_xsm=$enable_xsm $livepatch_runvars                          \
> > +          tree_qemuu=$TREE_QEMU_UPSTREAM                                     \
> > +          tree_xen=$TREE_XEN                                                 \
> > +          tree_seabios=$TREE_SEABIOS                                         \
> > +          $RUNVARS $BUILD_RUNVARS $BUILD_XEN_RUNVARS $arch_runvars           \
> > +          host_hostflags=arch-$arch,purpose-build                            \
> > +          revision_xen=$REVISION_XEN                                         \
> > +          revision_qemu=$REVISION_QEMU                                       \
> > +          revision_qemuu=$REVISION_QEMU_UPSTREAM                             \
> > +          revision_seabios=$REVISION_SEABIOS                                 \
> 
> These various xen build runvar settings seem to have mostly been
> copied from create_build_jobs.  I think they should be abstracted into
> a function.
> 
> Also of course you have two places where you create the job
> build-xen-freebsd.  Can we please have a shell function for that to
> avoid the duplication ?

Yes, let me try.

> > +proc run-job/build-xen-freebsd {} {
> > +    run-ts . xen-build-clang ts-xen-build + host -- clang=y SEABIOSCC=gcc \
> > +                                                    SEABIOSLD=/usr/local/bin/ld
> 
> This is quite ugly.  sg-run-job normally tries to be a bit more
> abstract.  I'm not sure exactly what to suggest.
> 
> Maybe a ts-xen-build-clang containing these arguments ?  Of course for
> a clang build on Linux /usr/local/bin/ld is wrong...

Maybe ts-xen-build-freebsd?

I went this route because it did not involve creating yet another
ts-build-* script, but if you think it's better I can add such a
script.

> It's also very odd that /usr/local/bin/ld is the right thing here.
> I'm not sure how the semantics of /usr/local ("locally installed")
> relate to Seabios's need for (presumably) binutils ld ?

Yes, SeaBIOS requires GNU ld in order to build, hence the setting of
those parameters.

On FreeBSD there's a difference from what's in base and on ports. base
is the basic system that contains a basic set of utilities, and it's
using a single repository:

https://svnweb.freebsd.org/base/head/

This contains the kernel, loader, and what's considered a minimal set
of tools to get a working UNIX system.

Everything else is installed from packages, and all those go by
default into /usr/local (you can change that to whatever path you
want). The set of packages to install is called ports, and the source
is not hosted in a FreeBSD repository, only the recipes to build them:

https://svnweb.freebsd.org/ports/head/

GNU binutils is moving outside of base, and is installed from a port
into /usr/local.

> Is it
> conventional on FreeBSD that /usr/local/bin/ld is binutils, or is that
> some kind of happenstance ?

It happens to be like that in this case because the
ts-build-prep-freebsd installs the binutils package in /usr/local and
that provides GNU ld in the specified path.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-07-03 16:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02  8:40 [PATCH 0/3] osstest: initial support for building Xen on FreeBSD Roger Pau Monne
2018-07-02  8:41 ` [PATCH 1/3] osstest: remove duplicate set_freebsd_runvars Roger Pau Monne
2018-07-03 15:10   ` Ian Jackson
2018-07-03 15:50     ` Roger Pau Monné
2018-07-03 16:53       ` Ian Jackson
2018-07-04  7:50         ` Roger Pau Monné
2018-07-02  8:41 ` [PATCH 2/3] osstest: set the make command to use for xen-build Roger Pau Monne
2018-07-03 15:12   ` Ian Jackson
2018-07-03 15:51     ` Roger Pau Monné
2018-07-03 16:54       ` Ian Jackson
2018-07-02  8:41 ` [PATCH 3/3] osstest: add FreeBSD Xen build job Roger Pau Monne
2018-07-03 15:22   ` Ian Jackson
2018-07-03 16:10     ` Roger Pau Monné [this message]
2018-07-03 16:56       ` Ian Jackson
2018-07-04  7:57         ` Roger Pau Monné

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=20180703161035.hbf66zm3plw4ocps@mac.bytemobile.com \
    --to=roger.pau@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=xen-devel@lists.xenproject.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.