[Exherbo-dev] Set CMake build type as build_option

Bo Ørsted Andresen zlin at exherbo.org
Tue Jun 7 19:32:53 UTC 2016


On Wed, Apr 20, 2016 at 07:54:16AM +0200, Bernd Steinhauser wrote:
> On 20/04/16 00:19, Kylie McClain wrote:
> > On Tue, Apr 19, 2016 at 4:10 PM, Bernd Steinhauser wrote:
> > > > Why a build_option? Why not a regular suboption or option?
> > > 
> > > Just because I thought it fits into build_options. But that's the only real
> > > reason.

I don't particularly find this very convincing. But I suppose what it really
boils down to is, whether we can come up with a description for that
build_option which will always fit? If not, do we really want the exheres-0
interface to permit custom descriptions for a build_option?

> > > (One of ) The reason against it would be that we currently just add a normal
> > > option "debug" if we handle something like that at all, but we could switch
> > > those over if we can define a general way how to do debug builds for
> > > autotools and other build systems. And if we would want to, of course.
> > > 
> > > No idea if there technical reasons against a build_options suboption and for
> > > regular suboptions, if there are, I'd like to know.
> > 
> > My (admittedly limited) understanding of the situation is that build_options
> > are not visible to the exheres environment. I remember hitting this whenever
> > I was fixing a bug with dev-lang/go, because I wanted to try and make the
> > package disable or fail if [build_options:dwarf_compress] was enabled,
> > because it appears to break go binaries.

If we were to do it, I think it would be an opt in build_option. Having the
option makes no sense if the package in question doesn't do anything with it,
so it should just declare when it does.

> > That's the main technical reason, that and that I believe you'd have to
> > actually dig into Paludis code to add options to build_options. So, that'd
> > probably complicated it a lot more than it is worth.

Not complicated.

> > I think just adding a [debug] option to the cmake.exlib that changes the type of
> > build would be more reasonable; we seem to use [debug] as the default option for
> > enabling debug features, or things helpful for debugging programs that are
> > changed at build time.
> > 
> Well, then it might be better to just use the debug option. Maybe paludis
> improves there at some point so we can integrate the debug option into
> build_options globally, where, in principle, it belongs imo. But it's not
> urgent.

Still don't understand this principle.

> Any opinion on the rest of the case?

The rest?

--
Bo Ørsted Andresen



More information about the Exherbo-dev mailing list