On Sun, May 20, 2012 at 09:45:08PM -0500, Jonathan Nieder wrote:
> I see. In that case I disagree with you. My first impression is that
> patching in LDFLAGS upstream is not simpler than fixing configure and
> adding TEST_LDFLAGS in a few places. The former is a maintainability
> hassle ("how do I decide whether to use LDFLAGS or TEST_LDFLAGS in
> each line") and makes the semantics of LDFLAGS versus TEST_LDFLAGS
> more difficult to explain. The latter would be just making the
> existing semantics more consistent.To be honest I don't care how the buildsystem gets fixed to respect the flags. I just provided one patch which I felt to be the easiest solution. If respecting TEST_LDFLAGS is a better solution, please go ahead. > However, that's kind of off-topic here. I could easily be convinced > that adding LDFLAGS everywhere is good, especially if others on the > zlib list seem to agree. The right place to have that discussion is > there. They are efficient and seem happy to hear from newcomers. I just want to fix the immediate problem with zlib. I'm not the maintainer but only noticed that a few flags were missing and thus tried to help by providing a patch which fixed the problem - even if it may have not been the optimal solution. Regards, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9
pgpUKyP22CImF.pgp
Description: PGP signature
