[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 Tue, Aug 27, 2019 at 11:59:33AM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 2/3] build: allow picking the env values for 
> compiler variables"):
> > On 20.08.2019 09:58, Roger Pau Monné  wrote:
> > > 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.
> 
> CC is set *specifically to cause build systems's like Xen's to use
> that compiler*.  That is its purpose.  It should be honoured, not
> ignored.
> 
> Likewise FORTIFY, even though it broke something.  FORTIFY_SOURCE was
> set specifically to cause the changes it did.  The people who set it
> didn't see all the implications, but that change *was* their design
> intent and the bugs were real bugs in what they were trying to do.
> 
> > Question is whether to take the above just for the hypervisor part
> > of the build, or also the tool stack etc ones.
> 
> *Definitely* for the toolstack build, we should honour CC et al.
> 
> The hypervisor is a more subtle question because people who set these
> variables often forget to think about kernel code, embedded code,
> etc.  That's what happened with FORTIFY_SOURCE.  However, I would
> argue that it is better, in such a situation, to honour the variable
> and break the build, than it is to simply ignore it.

I fully agree. It's true that some build systems will likely break
bulding Xen, but that's a build system issue, and we shouldn't try to
work around this in Xen. As said before, what build systems (like
travis or gitlab for instance) set in the environment should be
acknowledged by Xen, or else we are forcing everyone to have custom
workarounds for building Xen.

Thanks, Roger.

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

 


Rackspace

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