❦ 30 septembre 2013 11:30 CEST, Willy Tarreau <w...@1wt.eu> :
>> I would use `pcre-config --libs` and `pcre-config --cflags` instead. The
>> user can still override this on make command line.
>>
>> PCRE_CFLAGS := $(shell pcre-config --cflags)
>> PCRE_LIBS := $(shell pcre-config --libs)
>
> But these would still cause the issue we're currently facing because
> they'll add -L/usr/lib or whatever is in the system path, so that does
> not fix the issue. Really I'd rather get rid of pcre-config completely.
> Anyway, in cross-compile environments, you can't use it and you have
> to force the value otherwise you're screwed, and in local builds, you
> simply don't need to specify them.
For me, pcre-config --libs does not use `-L`. Dunno why this is the case
for Apollon.
For cross-compile, triplet-enabled pcre-config should be available (this
is tested by autoconf) but on cross-compile toolchain that I see
nowadays, the PATH is made such that you find pcre-config for
crosscompilation before the one for the system. I don't know if a user
is expected to rely on this.
>> As for the ordering of -L, I would expect the user to specify `make
>> LDFLAGS="-L/tmp/openssl/static"` and you rename the internal `LDFLAGS`
>> to something else (instead of introducing another variable, LDFLAGS is
>> the variable that a user can expect to override). $(LDFLAGS) will be
>> used early (as currently done), so the specified directory will be first
>> in the search path.
>
> That's interesting. In fact, the worst problem we have is that (except
> for ADDINC/ADDLIB), the variables the user can specify already hold a
> value and are overridden. That's how we added more and more variables,
> so that you can specify extra build information without losing existing
> ones.
>
> I've just checked, and all my build scripts already specify LDFLAGS, but
> just for passing -g/-s/-static (basically what we can expect in LDFLAGS),
> but none of them expects LDFLAGS to also override ARCH_FLAGS. So I think
> it could already improve things if instead of having :
>
> LDFLAGS = $(ARCH_FLAGS) -g
> ...
> $(LD) $(LDFLAGS) -o $@ $^ $(LDOPTS)
>
> we had :
>
> LDFLAGS = -g
> ...
> $(LD) $(ARCH_FLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS)
>
> or even ideally :
>
> ARCH_LDFLAGS = $(ARCH_FLAGS)
> LDFLAGS = -g
> ...
> $(LD) $(ARCH_LDFLAGS) $(LDFLAGS) -o $@ $^ $(LDOPTS)
>
> I think we wouldn't break existing build scripts by such a small change
> and would make it easier for packagers to force some paths without the
> risk of overriding the arch-specific flags.
Yes, this seems fine.
--
Avoid multiple exits from loops.
- The Elements of Programming Style (Kernighan & Plauger)
