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. Saludos, Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
