From owner-svn-src-head@freebsd.org Mon Jul 23 18:28:51 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D28D1051EDC for ; Mon, 23 Jul 2018 18:28:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9323891F1 for ; Mon, 23 Jul 2018 18:28:50 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 3b192547-8ea6-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 3b192547-8ea6-11e8-aff6-0b9b8210da61; Mon, 23 Jul 2018 18:28:45 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6NIShnA013614; Mon, 23 Jul 2018 12:28:43 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532370523.1344.167.camel@freebsd.org> Subject: Re: svn commit: r336640 - head/share/mk From: Ian Lepore To: Brad Davis , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Mon, 23 Jul 2018 12:28:43 -0600 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> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 18:28:51 -0000 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