On Tue, Apr 19, 2016 at 4:10 PM, Bernd Steinhauser <[email protected]> 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. > > (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. 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. 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. _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
