svn commit: r410612 - head/devel/libc++

[John Marino (FreeBSD)]

On 2016-03-09 19:10, Bryan Drewery wrote:
> It was accurate before though and is now redundant. The way synth 
> treats
> the result is inaccurate. The real behavior here is in 'make
> lib-depends', not 'make -V LIB_DEPENDS' which contains 0 logic. I had
> intended to upstream Poudriere's dependency check here into a 'make
> actual-lib-depends-list' or something but never did so.  It may even be
> redundant with some of the new work from bapt in Mk/Scripts now.

First I want to point out that the maintainer accepted my change and 
closed the bug report, so "revert the commit" should be off the table.

Secondly, classifying this as "accurate" is a stretch.  Even people that 
understand the dynamic are going to get caught by this dynamic.  I 
understand it and I've been caught by this a few times.

thirdly, this dynamic has a severe performance impact.
Right now synth scans all 26k ports with a single "make -V" command.  
You're telling me that to do this "correctly" synth now how to issue 
thousands of existence checks for libraries.

Fourth: I'm not advocating changing anything in the framework -- it's 
fine that this is a safety net.  I'm saying that LIB_DEPENDS or 
RUN_DEPENDS doesn't match the package, that a change to make it so won't 
meet resistance.


> The issue is with all _DEPENDS. RUN_DEPENDS= foo:origin is only applied
> when foo doesn't already exist in PATH. Same for FETCH/PATCH/BUILD
> depends, but it's only relevant here for RUN_DEPENDS and LIB_DEPENDS 
> due
> to registering in the package.

Only LIB_DEPENDS and RUN_DEPENDS is important.  Those are ones that are 
registered in the package.


> I don't like conditionalizing it here because it creates a dependency 
> of
> the built package on the system that built it. That sounds absurd but
> consider that LIB_DEPENDS is simply METADATA. The METADATA should
> generally be available to the package regardless of what was on the
> system that build it. Longterm it may make sense to have a package
> generated and use this LIB_DEPENDS as an optional dependency if it's 
> not
> on the installed system.

I don't know what you mean here.  The packages *are* distinct depending 
on the platform on which it's built.  The influence is already there, 
and changes like this one document that effect so it's clear.

> I think it will be far larger than that. We don't document nor commonly
> add exists() checks around RUN_DEPENDS and LIB_DEPENDS.  From the last
> time I looked at this the usage of it was fairly low.

I haven't measured this but there are not many ports that rebuild every 
time.  I think the number is very low.  People notice when it happens.


> This is why there is hesitation to throw away good tools and write new
> ones.  The existing behavior must be respected and otherwise fixed in
> all tools.  One does not simply write a replacement tool without
> understanding all of the behavior.  Poudriere took years to get right
> and it still is wrong in regards to handling DEPENDS_ARGS.

Well, no, when the existing behavior has problems then it's fair game to 
try to rectify it.  Sometimes they are simply side effects that the 
original designers flat-out missed.  I'm not saying that happened here, 
but I'm saying to claim legacy behavior is the best ever and can never 
been revisted I don't agree with.

Again, I don't mind that the behavior stays as a safety net, but the 
port shouldn't be designed to trigger it.


> Regardless of this specific commit, synth should be fixed to not assume
> RUN_DEPENDS and LIB_DEPENDS are unconditional, they are metadata and 
> the
> logic of lib-depends/run-depends should be used instead.

The maintainer was fine with the change.
I don't get this "metadata" reference.  It's a specification and it 
should be accurate.

By the way, I've seen this behavior cause unintended problems.  It's 
really not desireable at all.  For what? to have a makefile with less 
lines in it?  The conditional statements are well worth it.

John