[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/3] osstest: add FreeBSD Xen build job
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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |