[Dovecot] 1.1beta9 'make' fails on osx/Tiger, but OK on osx/Leopard (multiple definitions of symbol _hash_create)

[snowcrash]

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