[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 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. > 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. 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 |