> 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.
