let things be explicit has one big advantage - ensures that when things get built/commited thru rMake they will be in the exact same form as the committer intended, and as he got on is local box via cvc cook, as with things implicit, in the case of a missing buildReq, the package would build anyway, (with less functionallity), being explicit - the buildReqs miss gets noisy and build will fail. The drawback, is that one has to be careful when bumping releases, to make sure that those opts we set explicitly keep being default=auto upstream.
Above is one approach. the other possible approach is to get things locally, mook, and make sure for a given flavor that resulting changeset have equal content to the locally cooked one. In the end, matter of discipline. António On 07/24/2009 04:44 PM, Zhang Sen wrote: > Hi list, > > If a package has a configure option as default=auto, what's the > preferred way to deal with it in the recipe? Write --enable-this-feature > explicitly or let it be implicit? > > E.g. I am updating gmime, and it has --enable-mono as auto. I know it > would be enabled if proper entries are in buildReq (i.e. mono:runtime), > but should I really write --enable-mono? > > Seems trivial, but.. :) > > -zhang > > _______________________________________________ > Foresight-devel mailing list > [email protected] > http://lists.rpath.org/mailman/listinfo/foresight-devel > _______________________________________________ Foresight-devel mailing list [email protected] http://lists.rpath.org/mailman/listinfo/foresight-devel
