I think as a user it's a lot easier to use and understand if you're just instructed to say:
CPPFLAGS=-I/usr/local/include LDFLAGS=-I/usr/local/lib ./configure
instead of:
./configure --with-mysql=/usr/local --with-sqlite=/usr/local --with-pgsql=/usr/local --with-ten-other-packages=/usr/local
again, i don't agree. LDFLAGS, CPPFLAGS, etc are _global_ var instances ... used by autofoo across the entier install. often end up with stuff linked-in where you don't necessarily need/want it.
also, lots of other apps seem to provide the option. i suppose they do it for a reason ...
but it's simply personal preference -- and, like i said, ultimately your call! :-)
Binary packages sometimes install things to different locations than a standard installation. Like the header might not be in /usr/include/, but in /usr/include/package/. For that case this doesn't really work.
well, first, i don't *use* binary packages ... i build from source.
but, anyway, it works just fine -- if you define/ues the vars properly. i do it all the time with other apps.
And lots of bloat to both configure code and ./configure --help..
some say bloat, some say flexibility. again, just opinion. if lean-as-possible is the goal, then you're absolutely right.
if, however, you want to allow folks to built dovecot on *their* system layout -- not just distros' -- then some flexibility needs to be there.
-I and -L don't really matter if they're in global CPPFLAGS/LDFLAGS.
hm? items def'd in LDFLAGS don't matter? then why your question about why -lsqlite is linked in? it's _only_ coming from LDFLAGS ... apparently not as you expected, no?
anyway, i can simply workaround lack of flexibility if/as needed. no changes to 'required'.
cheers.