On Sat, Jan 24, 2009 at 07:34:44AM -0800, [email protected] wrote: > > Date: Sat, 24 Jan 2009 01:47:57 +0100 > > From: Sylvain Beucler <[email protected]> > > Content-Disposition: inline > > > > Hi, > > > > When compiling gnupdf I noticed that features are enabled or disabled > > based on their presence on the system. > > > > > > I don't like this, because users usually don't know if they compiled > > the library the recommended way or not. > > Hi Beuc, > > I agree with you, note that the configure script prints a summary when > finishes. Maybe what we can do is to add to this summary what features are > recommended/essential, or to the README or INSTALL file.
Briefly: let's use an error rather than a recommendation. I saw the summary, that's nice but I think we can do better. Btw, I usually don't have the patience to read README or INSTALL, I expect './configure' to do the Right Thing and warn me if there's any problem. I'm pretty sure I'm not alone :) I think that, to improve the consistency of gnupdf from various downstream (future) distributors, it's better to be careful and make sure people compile what we recommend. For example, make it an error to produce version without jbig support unless that's explicitely specified in the distributor's packaging instructions (I mean .spec, debian/rules and such). This also avoids a silent change if at some point, one of the library isn't detected anymore. Last, I think people will appreciate a good error when something is missing rather than a recommendation that will be lost in the growing list of things we have to mention in the summary :) -- Sylvain
