Re: Bits from dpkg developers - dpkg 1.16.1
* Ian Jackson <firstname.lastname@example.org> [110927 20:21]:
> Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> > things to be in a users environment, so a package's rules file should
> > in my eyes not depend on them not being set or having any values sensible.
> This tells us more about the reliability of your opinion than it does
> about build systems.
Thanks in advance for keeping personal attacks out of the discussion
in the future.
> In general, upstream build systems cannot be
> relied on do to anything sane or predictable if they are run with
> these variables in the environment.
While some upstream build systems have problems with those flags,
most broken ones simply ignore them (unlike setting them as
make variables on the command line, where much more break).
automake/autoconf usually do a very good job on respecting those
variables and if some project fails to handle those properly, they
usually do so in not respecting a setting in the environment at
configure time (by overwriting it) or by adding stuff to it at
configure time so that running make with different flags given
as arguments misses those arguments (which is well for additional
warning flags and stuff like that but not for things like including
private headers), but both of those cases also cause no problem.
If mostly dealing with auto* projects, having some
CPPFLAGS=-I~/stuff/include and LDFLAGS=-L~/stuff/lib
together with some LD_LIBRARY_PATH is an very easy way to
develop as user without root priviledges (just needing
--prefix=~/stuff then for all configure runs).
Bernhard R. Link