On 20/04/16 00:19, Kylie McClain wrote:
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.
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.
Any opinion on the rest of the case?
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
