Date: Tue, 6 Nov 2018 17:02:49 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Adam Weinberger <adamw@adamw.org> Cc: freebsd-ports@freebsd.org Subject: Re: Intention of the clean target vs clean-depends Message-ID: <226686c8-4443-d4e0-5b3d-6e94add0a8ec@omnilan.de> In-Reply-To: <CAP7rwchJgZDewqg0PS7BEoQ0JDSHte2kV2ROGYd1Z-pC%2B__1Mw@mail.gmail.com> References: <1ec31adb-5916-45de-dd9f-ee6be5a97a44@omnilan.de> <61d03ae6-4e88-291e-d68f-bfa35ec33b01@omnilan.de> <CAP7rwchJgZDewqg0PS7BEoQ0JDSHte2kV2ROGYd1Z-pC%2B__1Mw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 06.11.2018 um 14:10 schrieb Adam Weinberger:
> On Tue, Nov 6, 2018 at 12:38 AM Harry Schmalzbauer <freebsd@omnilan.de> wrote:
>>
>> Am 05.11.2018 um 13:03 schrieb Harry Schmalzbauer:
>>> Hello,
>>>
>>> I'm about to overhaul some scripts and continue wondering why 'make
>>> clean' removes ${WRKDIR} of all dependencies, although there's the
>>> clean-depends target.
>>> The comment in bsd.ports.mk makes me think 'clean' shouldn't delete
>>> dependencies:
>>> # clean - Remove ${WRKDIR} and other temporary files
>>> used for building.
>>> # clean-depends - Do a "make clean" for all dependencies.
>>>
>>> Thanks fpr clarification,
>>
>> Hello,
>>
>> I'm really interested why it is how it is.
>> I'd highly appreciate if someone can confirm that the current behaviour
>> of the clean: target is the intended behaviour.
>> If so, the clean-depends: can be retired, can it?
>> I'm ignoring this – to my understanding – oddity for more then a decade,
>> without ever stumbling over any scenario where the behaviour would have
>> been self clarifiying.
>> For now I'm using the clean-wrkdir: target instead of clean:, but since
>> nobody answered yet, I guess my question is unclear or I'm missing
>> somthing ultimate obvious, so the question isn't unclear but stupid?!?
>>
>> Thanks,
>>
>> -harry
>
> Hi Harry,
>
> It is quite intentional. If a port is half-built, or if it's built
> with a previous version, running "make install" on it can install the
> wrong version or potentially error out (especially if any of its deps
> have changed). It's imperative that all dependencies be in a clean
> state before building a target. "make clean" provides a single
> entry-point to put the tree in a clean state.
>
> Back before packages actually worked and building from the tree was
> the norm, getting people to run "make clean" before "make install" was
> like pulling teeth. Separating clean: from clean-depends: would have
> been disastrous. So no, it's not a mistake, and it works as intended.
>
> I think the problem is the comment. The comment for clean-depends
> should probably be removed, as it's not expected that end-users will
> run it, and the comment for clean: could be "Remove ${WRKDIR} and
> other temporary files used for building from this port and all its
> dependencies." What do you think?
Thanks a lot for your attention.
I've always wanted to have a little smarter solution than brute-force
recompiling ;-)
But I'm not up to date with the improvements and modifications (mainly
USES) since PKG_NG times and possibly also the user base changed/will
change, so wasting CPU cycles compiling with standard options will
become a increasingly seldom ports usage, which is a reason not to spend
resources for user experience improvmenets – although I guess FreeBSD
will continue to attract users exactly searching for that kind of support.
So what I think could be improved immediately is that the clean: target
only wipes runtime dependencies instead of also build-time dependencies.
[and keep the clean-depends target doing the current extensive clean for
all recursive build-depends]
To verify myself if that's really/still true, I took a quick look and
found the ${CLEAN_DEPENDENCIES}: target, which seems to be heavily
changed due to FLAVOR birth and I can't get a quick overview, so probing
a real world example clearly shows my biggest problem with 'make clean'
in it's current state:
preed:/usr/ports/mail/sendmail/#:132 make run-depends-list
/usr/ports/security/cyrus-sasl2
/usr/ports/dns/libidn2
/usr/ports/devel/icu
/usr/ports/net/openldap24-client
/usr/ports/security/cyrus-sasl2-saslauthd
preed:/usr/ports/mail/sendmail/#:133 make clean
===> Cleaning for groff-1.22.3
===> Cleaning for ghostscript9-agpl-base-9.25_1
===> Cleaning for openjpeg-2.3.0_2
===> Cleaning for cmake-3.12.3
===> Cleaning for py27-sphinx-1.6.5_1,1
:
… snipping 28 lines additional py27-ports
:
===> Cleaning for py27-imagesize-0.7.1
===> Cleaning for ca_root_nss-3.40
===> Cleaning for py27-typing-3.6.4
===> Cleaning for ncurses-6.1.20180728
===> Cleaning for curl-7.62.0
===> Cleaning for libnghttp2-1.34.0
===> Cleaning for jsoncpp-1.8.1_4
===> Cleaning for scons-3.0.1
===> Cleaning for libuv-1.23.2
===> Cleaning for rhash-1.3.5
===> Cleaning for libarchive-3.3.3,1
===> Cleaning for lzo2-2.10_1
===> Cleaning for ninja-1.8.2,2
===> Cleaning for lcms2-2.9
===> Cleaning for tiff-4.0.9_1
===> Cleaning for jbigkit-2.1_1
===> Cleaning for jpeg-turbo-2.0.0
===> Cleaning for nasm-2.13.03,1
===> Cleaning for cups-2.2.8_1
===> Cleaning for avahi-app-0.7_1
===> Cleaning for intltool-0.51.0_1
===> Cleaning for p5-XML-Parser-2.44
===> Cleaning for libdaemon-0.14_1
===> Cleaning for dbus-glib-0.108
===> Cleaning for dbus-1.10.16_1
===> Cleaning for minixmlto-0.0.2_1
===> Cleaning for docbook-xsl-1.79.1,1
===> Cleaning for xmlcatmgr-2.2_2
===> Cleaning for docbook-1.5
===> Cleaning for docbook-sgml-4.5_1
===> Cleaning for iso8879-1986_3
===> Cleaning for docbook-xml-5.0_3
===> Cleaning for xmlcharent-0.3_2
===> Cleaning for sdocbook-xml-1.1_2,2
===> Cleaning for libxslt-1.1.32
===> Cleaning for libgcrypt-1.8.4
===> Cleaning for libgpg-error-1.32
===> Cleaning for html2text-1.3.2a
===> Cleaning for gdbm-1.13_1
===> Cleaning for gobject-introspection-1.56.1,1
===> Cleaning for cairo-1.15.12,2
===> Cleaning for xcb-util-renderutil-0.3.9_1
===> Cleaning for xorg-macros-1.19.2
===> Cleaning for libxcb-1.13.1
===> Cleaning for check-0.12.0
===> Cleaning for xcb-proto-1.13
===> Cleaning for bison-3.1,1
===> Cleaning for python36-3.6.7
===> Cleaning for sendmail-8.15.2_12
preed:/usr/ports/mail/sendmail/#:131 make build-depends-list
/usr/ports/ports-mgmt/pkg
/usr/ports/textproc/groff <- that's where the list get's really long for
it's run+build dependencies
/usr/ports/security/cyrus-sasl2
/usr/ports/dns/libidn2
/usr/ports/devel/icu
/usr/ports/net/openldap24-client
If cleaning runtime dependencies is enough or if there are practical
needs for the package-depends-list to be cleand, needs some attention.
But I have no idea why we want to clean all those build-only
dependencies (of other dependencies).
I have to admit that I don't get/like the idea of the FLAVOR extension
to the ports system. And maybe that's a new obstacle for any
modifications to the clean: target. But the current behaviour has
always been a significant time/energy waster for my setups, which I
haven't worked around yet. But I'm about to do it this time, so that
I'm utilizing only clean-wrkdir:, taking care of runtime dependencies
externally
(maybe I can reuse some rather poor code I've written to work arround
the USE_PACKAGE_DEPENDS problems, where subsequent dependencies are
resolved by pkg_add/pkg instead of the ports, which must end up in
inconsistent partial rebuilds. My workaround was to check if ports
PKGFILE matches the dependency package pkg_add/pkg would install and if
not, intercept and build a new PKGFILE. Sorry for bringing in another
topic, but in my opinion it's the same kind of design problem).
It hink your proposed changes to the comments section of bsd.ports.mk
should be done sooner than later, although it's been unclear for such a
long time ;-)
Thanks,
-harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?226686c8-4443-d4e0-5b3d-6e94add0a8ec>