Date: Wed, 09 Mar 2016 19:27:38 +0100 From: "John Marino (FreeBSD)" <freebsd.contact@marino.st> To: Bryan Drewery <bdrewery@freebsd.org> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r410612 - head/devel/libc++ Message-ID: <986126efd5470f18d599ad492e1f56b0@secure.marino.st> In-Reply-To: <56E06701.1090803@FreeBSD.org> References: <201603081248.u28Cmpw6061510@repo.freebsd.org> <56DFADDC.1050204@FreeBSD.org> <0b8d469c87c4688af433ad0a702e419e@secure.marino.st> <56E06701.1090803@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?986126efd5470f18d599ad492e1f56b0>