svn commit: r336640 - head/share/mk

[Ian Lepore]

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