LLNL XDIR Version 2.0, October 23, 1995 LLNL XDIR, an OSF/Motif-based FTP client, provides a graphical user interface for drag-and-drop file transfer. LLNL XDIR simultaneously displays any number of directories for any number of hosts, with each directory being displayed in its own window. LLNL XDIR supports powerful directory browsing capability, including iconic and hierarchical views. One of LLNL XDIR's most powerful features is its ability to search directory structures (even across multiple hosts) for entry names that match a specified pattern. LLNL XDIR is meant to be the successor to LLNL XFTP, another graphical FTP client. LLNL XDIR is considerably more sophisticated than LLNL XFTP, and has all of its functionality. LLNL XDIR is a component of the Intelligent Archive, which is currently under development at LLNL. LLNL XDIR was written by Neale Smith of the Lawrence Livermore National Laboratory, which is operated by the University of California. ished>2017-11-30T15:50:30+00:00 32512cab3e8dd90b7cd0525bb5dc98007db431e2 Ports using USE_PYTHON=distutils are now flavored. They will automatically get flavors (py27, py34, py35, py36) depending on what versions they support. There is also a USE_PYTHON=flavors for ports that do not use distutils but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if using distutils but flavors are not wanted. A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been added to cope with Python ports that did not have the Python PKGNAMEPREFIX but are flavored. USES=python now also exports a PY_FLAVOR variable that contains the current python flavor. It can be used in dependency lines when the port itself is not python flavored. For example, deskutils/calibre. By default, all the flavors are generated. To only generate flavors for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf. In all the ports with Python dependencies, the *_DEPENDS entries MUST end with the flavor so that the framework knows which to build/use. This is done by appending '@${PY_FLAVOR}' after the origin (or @${FLAVOR} if in a Python module with Python flavors, as the content will be the same). For example: RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR} PR: 223071 Reviewed by: portmgr, python Sponsored by: Absolight Differential Revision: https://reviews.freebsd.org/D12464
  Ports using USE_PYTHON=distutils are now flavored.  They will
  automatically get flavors (py27, py34, py35, py36) depending on what
  versions they support.

  There is also a USE_PYTHON=flavors for ports that do not use distutils
  but need FLAVORS to be set.  A USE_PYTHON=noflavors can be set if
  using distutils but flavors are not wanted.

  A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
  added to cope with Python ports that did not have the Python
  PKGNAMEPREFIX but are flavored.

  USES=python now also exports a PY_FLAVOR variable that contains the
  current python flavor.  It can be used in dependency lines when the
  port itself is not python flavored.  For example, deskutils/calibre.

  By default, all the flavors are generated.  To only generate flavors
  for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
  BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.

  In all the ports with Python dependencies, the *_DEPENDS entries MUST
  end with the flavor so that the framework knows which to build/use.
  This is done by appending '@${PY_FLAVOR}' after the origin (or
  @${FLAVOR} if in a Python module with Python flavors, as the content
  will be the same).  For example:

    RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}

PR:		223071
Reviewed by:	portmgr, python
Sponsored by:	Absolight
Differential Revision:	https://reviews.freebsd.org/D12464