Date: Thu, 22 Feb 2001 10:04:40 +0200 From: Maxim Sobolev <sobomax@FreeBSD.org> To: ports@FreeBSD.org Cc: asami@FreeBSD.org, roam@FreeBSD.org, lioux@FreeBSD.org, reg@FreeBSD.org, kris@FreeBSD.org Subject: [Fwd: Proposal: PLIST filtering rules] Message-ID: <3A94C818.8596A12E@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
C'mon guys, please allocate several minutes to read proposal below and respond
to it.
Thank you in advance!
-Maxim
-------- Original Message --------
Subject: Proposal: PLIST filtering rules
Date: Tue, 20 Feb 2001 17:55:50 +0200
From: Maxim Sobolev <sobomax@FreeBSD.org>
Organization: Vega International Capital
To: ports@FreeBSD.org
CC: asami@FreeBSD.org
Hi folks,
I do not know what others feel, but recent "legalisation" of PLIST %%PORTDOC:%%
hack is really pissses me off and forced to think about other ways to do the
same thing. The following reasons caused my bad feelings about massive
%%PORTDOC:%% usage in PLISTs:
1. It makes PLIST more cryptic and less human-readable;
2. It makes impossible to sort PLIST using simple tools;
3. As a consequence of 1 and 2 it makes ports updates more difficult.
After thinking this out, I found that at least one option was left unexplored.
I mean possibility to introduce simple egrep(1) filtering rules for PLIST. Let
me show a simple typical example of the %%PORTDOC:%% infected PLIST:
--*pkg-plist*--
bin/foo
share/foo/foo.dat
%%PORTDOC:%%share/doc/foo/1.txt
%%PORTDOC:%%share/doc/foo/2.txt
%%PORTDOC:%%share/doc/foo/3.txt
@dirrm share/foo
%%PORTDOC:%%@dirrm share/doc/foo
As you can see, even such simple example looks really ugly, while many
real-world ports do have much more that 3 files and several subdirectory levels
in share/doc, so to speak.
However, as it should be clear from the example above, in the most cases all
those complexities could be avoided if there is an ability to filter out lines
matching two simple regex patterns: "^share/doc/foo" and "^@dirrm
share/doc/foo". It should be noted, however, that line filtering is not
intended to replace PLIST_SUB, and in some complex cases PLIST_SUB should be
used instead.
Hence, it is proposed to introduce PLIST filtering rules, say PLIST_FIN and
PLIST_FOUT, which are to be a set of egrep(1)-style patterns for lines that are
to be included into and filtered out of PLIST. By default PLIST_FIN should be a
pattern matching any string, while PLIST_FOUT a pattern that doesn't match
anything. After such feature has been introduced %%PORTDOC:%% could be removed
from the exmple above and replaced with:
--*Makefile*--
PLIST_FOUT= "^share/doc/foo" "^@dirrm share/doc/foo"
It most cases it could be simplified even further:
--*bsd.port.mk*--
.if defined(NOPORTDOCS)
PLIST_FOUT?= "^share/doc/${PORTNAME}" "^@dirrm share/doc/${PORTNAME}"
.endif
Another interesting possibility opens by combining proposed PLIST_FOUT with
existing PLIST_SUB. This combination allows introduce possibility to flag
conditional files in the PLIST, for example:
--*pkg-plist*--
bin/gnome-foo %%GNOME%%
bin/foo
bin/kde-foo %%KDE%%
--*Makefile*--
[...]
.if !defined(HAVE_KDE)
PLIST_FOUT+= ${KDE_PATTERN}
.else
PLIST_SUB+= 's|${KDE_PATTERN}||'
.endif
.if !defined(HAVE_GNOME)
PLIST_FOUT+= ${GNOME_PATTERN}
.else
PLIST_SUB+= 's|${GNOME_PATTERN}||'
.endif
--*bsd.kde.mk*--
[...]
KDE_PATTERN= \t%%KDE%%$$
--*bsd.gnome.mk*--
[...]
GNOME_PATTERN= \t%%GNOME%%$$
------------------
As you can see, unlike current PLIST_SUB solution, PLIST in this case looks
clean, more eye candy and could be sorted easily either using standard tools
like sort(1) or by the hand.
As usually, I would like to hear comments/opinions/suggestions/bikesheds/etc
regarding this proposal. If they are positive, I'm ready to provide a patch
implementing this feature.
-Maxim
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A94C818.8596A12E>