Date: Mon, 23 Jul 2018 12:28:43 -0600 From: Ian Lepore <ian@freebsd.org> To: Brad Davis <brd@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r336640 - head/share/mk Message-ID: <1532370523.1344.167.camel@freebsd.org> In-Reply-To: <1532370035.3251993.1450222760.4825785F@webmail.messagingengine.com> References: <201807231611.w6NGB3gh074167@repo.freebsd.org> <1532362918.1344.145.camel@freebsd.org> <1532364494.2401755.1450115552.31CB163C@webmail.messagingengine.com> <1532364842.1344.164.camel@freebsd.org> <1532370035.3251993.1450222760.4825785F@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2018-07-23 at 12:20 -0600, Brad Davis wrote: > On Mon, Jul 23, 2018, at 10:54 AM, Ian Lepore wrote: > > > > On Mon, 2018-07-23 at 10:48 -0600, Brad Davis wrote: > > > > > > On Mon, Jul 23, 2018, at 10:21 AM, Ian Lepore wrote: > > > > > > > > > > > > On Mon, 2018-07-23 at 16:11 +0000, Brad Davis wrote: > > > > > > > > > > > > > > > Author: brd > > > > > Date: Mon Jul 23 16:11:03 2018 > > > > > New Revision: 336640 > > > > > URL: https://svnweb.freebsd.org/changeset/base/336640 > > > > > > > > > > Log: > > > > > Add the initial DIRS infrastructure for creating > > > > > directories > > > > > with the > > > > > necessary owner, group, mode and flags. > > > > > > > > > > Approved by: bapt (mentor) > > > > > Differential Revision: https://reviews.freebsd.org/D > > > > > 1640 > > > > > 5 > > > > > > > > > > Added: > > > > > head/share/mk/bsd.dirs.mk (contents, props changed) > > > > > Modified: > > > > > head/share/mk/bsd.README > > > > > > > > > > Modified: head/share/mk/bsd.README > > > > > ============================================================= > > > > > ==== > > > > > ============= > > > > > --- head/share/mk/bsd.README Mon Jul 23 15:36:55 2018 > > > > > (r336639) > > > > > +++ head/share/mk/bsd.README Mon Jul 23 16:11:03 2018 > > > > > (r336640) > > > > > @@ -22,6 +22,7 @@ bsd.confs.mk - install of > > > > > configuration files > > > > > bsd.cpu.mk - sets CPU/arch-related variables > > > > > (included from sys.mk) > > > > > bsd.crunchgen.mk - building crunched binaries using > > > > > crunchgen(1) > > > > > bsd.dep.mk - handle Makefile dependencies > > > > > +bsd.dirs.mk - handle directory creation > > > > > bsd.doc.mk - building troff system documents > > > > > bsd.endian.mk - TARGET_ENDIAN=1234(little) or > > > > > 4321 (big) for target > > > > > bsd.files.mk - install of general purpose > > > > > files > > > > > @@ -291,6 +292,18 @@ CFLAGS Flags to the > > > > > compiler > > > > > when creating C objects. > > > > > CLEANDIRS Additional files (CLEANFILES) and > > > > > directories > > > > > (CLEANDIRS) to > > > > > CLEANFILES remove during clean and cleandir > > > > > targets. "rm > > > > > -rf" and > > > > > "rm -f" are used, respectively. > > > > > + > > > > > +DIRS A list of variables referring to > > > > > directories. For example: > > > > > + > > > > > + DIRS+= FOO > > > > > + FOO= /usr/share/foo > > > > > + > > > > > + Owner, Group, Mode and Flags are handled by > > > > > FOO_OWN, > > > > > + FOO_GRP, FOO_MODE and FOO_FLAGS, > > > > > respectively. > > > > > + > > > > > + This allows FILESDIR to be set to FOO, and > > > > > the > > > > > directory > > > > > + will be created before the files are > > > > > installed > > > > > and the > > > > > + dependencies will be set correctly. > > > > > > > > > > DPADD Additional dependencies for the > > > > > program. Usually used for > > > > > libraries. For example, to depend on the > > > > > compatibility and > > > > > > > > > > Added: head/share/mk/bsd.dirs.mk > > > > > ============================================================= > > > > > ==== > > > > > ============= > > > > > --- /dev/null 00:00:00 1970 (empty, because > > > > > file is > > > > > newly added) > > > > > +++ head/share/mk/bsd.dirs.mk Mon Jul 23 16:11:03 2018 > > > > > > > > > > (r336640) > > > > > @@ -0,0 +1,42 @@ > > > > > +# $FreeBSD$ > > > > > +# > > > > > +# Directory permissions management. > > > > > + > > > > > +.if !target(____) > > > > > +____: > > > > > +# List of directory variable names to install. Each > > > > > variable > > > > > name's value > > > > > +# must be a full path. If non-default permissions are > > > > > desired, > > > > > _MODE, > > > > > +# _OWN, and _GRP may be specified. > > > > > +DIRS?= > > > > > + > > > > > +. for dir in ${DIRS:O:u} > > > > > +. if defined(${dir}) && !empty(${dir}) > > > > > +# Set default permissions for a directory > > > > > +${dir}_MODE?= 0755 > > > > > +${dir}_OWN?= root > > > > > +${dir}_GRP?= wheel > > > > > +. if defined(${dir}_FLAGS) && !empty(${dir}_FLAGS) > > > > > +${dir}_FLAG= -f ${${dir}_FLAGS} > > > > > +. endif > > > > > + > > > > > +. if defined(NO_ROOT) > > > > > +. if !defined(${dir}TAGS) || ! > > > > > ${${dir}TAGS:Mpackage=*} > > > > > +${dir}TAGS+= package=${${dir}PACKAGE:Uruntime > > > > > } > > > > > +. endif > > > > > +${dir}TAG_ARGS= -T ${${dir}TAGS:[*]:S/ /,/g} > > > > > +. endif > > > > > + > > > > > +installdirs: installdirs-${dir} > > > > > + > > > > > +installdirs-${dir}: ${DESTDIR}${${dir}} > > > > > + > > > > > +${DESTDIR}${${dir}}: > > > > > + @${ECHO} installing DIRS ${dir} > > > > > + ${INSTALL} ${${dir}TAG_ARGS} -d -m ${${dir}_MODE} -o > > > > > ${${dir}_OWN} \ > > > > > + -g ${${dir}_GRP} ${${dir}_FLAG} > > > > > ${DESTDIR}${${dir}} > > > > > +. endif > > > > > + > > > > > +realinstall: installdirs-${dir} > > > > > +. endfor > > > > > + > > > > > +.endif > > > > > > > > > Having a variable named DIRS seems like asking for name clashes > > > > with > > > > peoples' existing makefiles (people do use the freebsd build > > > > infrastructure to build out-of-tree code). Could it be named > > > > maybe > > > > CREATEDIRS (taking a precedent-clue from CLEANDIRS)? > > > I suppose that is possible, but it seems like other people could > > > be > > > using CREATEDIRS, or anything else we might choose as well. Do > > > you > > > have an example of someone using DIRS already? > > > > > > So I am kind of doubtful that changing this to something else > > > would > > > avoid the problem entirely.. > > > > > > > > > Regards, > > > Brad Davis > > > > > The only way to avoid it entirely would be to declare that anything > > starting with FREEBSD belongs to us and consistantly use it. That > > ship > > sailed about 30 years ago. > > > > My theory is that the longer the name is, the less likely it is to > > clash. Of course, any name you come up with that's good and > > sensible > > and self-documenting is exactly the kind of name that someone else > > is > > likely to come up with as well. > Good point. But unless someone has an active example, I think I'll > just leave it for now. > There is, of course, no way to provide an active example for "this name is common enough that it might be used in out-of-tree code we are unaware of" since "are unaware of" is the operative phrase. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1532370523.1344.167.camel>