El 23/06/08 09:45 Felipe Sateler escribió: > El 23/06/08 02:37 Raphael Hertzog escribió: > > > > I don't know if we want to put both in the same module or if we need > > > > to come up with a different name (or a sub-module maybe). > > > > > > I can try doing this, although I couldn't find an appropriate name > > > (perhaps Source::BuildOptions?). The idea would be to add one function > > > per build option, or one function that processes them all? I think it's > > > best to do one function per build option, since an option can touch any > > > part of the process. > > > > I'm not yet 100% sure what the best design is. I think both > > DEB_BUILD_OPTIONS and Build-Options are going to be closely tied > > anyway... Build-Options is a way to express that the package supports a > > set of functionalities and often those will be enabled through a keyword > > in DEB_BUILD_OPTIONS. > > > > As such, it probably makes sense to add support for both in the same > > module but with different commands to allow checking one set or the other > > or both. > > I'm not really sure this is a good idea. The way I see it, Build-Options is > most useful for declaring that the package handles something that would > break a normal package (such as build-arch). Thus, I think they will be > boolean (or should, at least: I don't see the usefulness of parallel=n in > Build-Options). DEB_BUILD_OPTIONS doesn't have these characteristics, as a > package that doesn't handle a given option simply ignores it, and that > options can have any type. As such, I think it is a good idea to provide > separate modules, since it makes the Build-Options support simpler.
Also, there is another important difference: Build-Options are specified by the package, while DEB_BUILD_OPTIONS are specified by the builder. I think it can be confusing if both are in the same module. Saludos, Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
