[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.