Re: [Xen-devel] [PATCH 2/3] build: allow picking the env values for compiler variables

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.08.2019 09:58, Roger Pau Monné  wrote:
> On Mon, Jul 29, 2019 at 03:35:36PM +0000, Jan Beulich wrote:
> > On 26.07.2019 15:33, Roger Pau Monne wrote:
> > > Don't force the usage of the hardcoded compiler values if those are
> > > already set on the environment. This allows the Xen build system to
> > > correctly pick CC/CXX values present on the environment, and fixes the
> > > usage of those by the Gitlab CI test system.
> > >
> > > Note that without this fix the Xen build system will completely ignore
> > > any CC or CXX values set on the environment, and the only way to pass
> > > a different CC or CXX is to overwrite it on the make command line.
> > Now the question is: Do we possibly want it to be that way? I've always
> > been of the opinion that inheriting something that happens to be (left?)
> > set in the environment is not a good idea.
> Then what's the point in having an environment with stuff anyway if
> Xen build is just going to ignore it?
>
> I don't have things 'left' in the environment, neither have most build
> systems AFAIK. I do have things set that I want the build to
> acknowledge, instead of fight against it.
My view is this: XEN_* things coming from the environment are fine.
Generic (i.e. project agnostic) variables (like CC) otoh would
better be ignored, as it's not clear for what purpose they've been
set. (Istr a case where some FORTIFY option was set by RPM build
environments, breaking our build.) They may well have been meant
for some other project.

Question is whether to take the above just for the hypervisor part
of the build, or also the tool stack etc ones.

> > Hence I've been welcoming all
> > changes that removed dependencies on settings possibly coming from the
> > environment. (Exceptions of course are XEN_* environment variables we
> > specifically evaluate.)
> >
> > As a result I'm inclined to nak this patch, but I'm open to arguments.
> IMO doing things like this is going to make Xen harder to package for
> everyone, since distro build systems and test systems (like Travis or
> Gitlab) expect the build system to pick the relevant
> compiler/toolchain variables from the environment. Not doing it this
> way means we need to adapt each build system to work with Xen.
Well, what you describe means customizing the environment. What I
suggest means customizing the make command line. But it's customization
in either case. It _may_ happen that customizing the environment for
Xen means doing nothing, and the same settings being useful for other
projects as well. But this doesn't have to be this way and, as said
above, has been causing problems.

Furthermore - what do you do if different parts of the tree (xen/,
tools/, stubdom/) want to have different settings in effect? To me
it's quite a bit more natural to have three different but specific
make invocations, rather than fiddling with various env vars between
any two of them.

Jan

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