Revision: 75972
http://sourceforge.net/p/brlcad/code/75972
Author: starseeker
Date: 2020-05-28 20:47:56 +0000 (Thu, 28 May 2020)
Log Message:
-----------
Try to reduce the clutter accumulating at the toplevel doc directory.
Modified Paths:
--------------
brlcad/trunk/doc/CMakeLists.txt
Added Paths:
-----------
brlcad/trunk/doc/README/
brlcad/trunk/doc/README/README.AIX
brlcad/trunk/doc/README/README.BSD
brlcad/trunk/doc/README/README.IRIX
brlcad/trunk/doc/README/README.Linux
brlcad/trunk/doc/README/README.MacOSX
brlcad/trunk/doc/README/README.OSCON-2014
brlcad/trunk/doc/README/README.Solaris
brlcad/trunk/doc/README/README.VAX
brlcad/trunk/doc/README/README.Windows
brlcad/trunk/doc/notes/
brlcad/trunk/doc/notes/TODO.BREP
brlcad/trunk/doc/notes/TODO.shaded_displays
brlcad/trunk/doc/notes/brep.txt
brlcad/trunk/doc/notes/bsd_semaphore_bug.txt
brlcad/trunk/doc/notes/bu_opt_design_notes.txt
brlcad/trunk/doc/notes/cmake_vars.txt
brlcad/trunk/doc/notes/csv_to_comgeom.txt
brlcad/trunk/doc/notes/cvs.txt
brlcad/trunk/doc/notes/ecosystem.dot
brlcad/trunk/doc/notes/editors.txt
brlcad/trunk/doc/notes/history.txt
brlcad/trunk/doc/notes/hypot.txt
brlcad/trunk/doc/notes/implicit_constraints.txt
brlcad/trunk/doc/notes/lcov.txt
brlcad/trunk/doc/notes/mater.txt
brlcad/trunk/doc/notes/matrix.txt
brlcad/trunk/doc/notes/regions.txt
brlcad/trunk/doc/notes/rounding.txt
brlcad/trunk/doc/notes/tool_categories.txt
Removed Paths:
-------------
brlcad/trunk/doc/README.AIX
brlcad/trunk/doc/README.BSD
brlcad/trunk/doc/README.IRIX
brlcad/trunk/doc/README.Linux
brlcad/trunk/doc/README.MacOSX
brlcad/trunk/doc/README.OSCON-2014
brlcad/trunk/doc/README.Solaris
brlcad/trunk/doc/README.VAX
brlcad/trunk/doc/README.Windows
brlcad/trunk/doc/TODO.BREP
brlcad/trunk/doc/TODO.shaded_displays
brlcad/trunk/doc/brep.txt
brlcad/trunk/doc/bsd_semaphore_bug.txt
brlcad/trunk/doc/bu_opt_design_notes.txt
brlcad/trunk/doc/cmake_vars.txt
brlcad/trunk/doc/csv_to_comgeom.txt
brlcad/trunk/doc/cvs.txt
brlcad/trunk/doc/ecosystem.dot
brlcad/trunk/doc/editors.txt
brlcad/trunk/doc/history.txt
brlcad/trunk/doc/hypot.txt
brlcad/trunk/doc/implicit_constraints.txt
brlcad/trunk/doc/lcov.txt
brlcad/trunk/doc/mater.txt
brlcad/trunk/doc/matrix.txt
brlcad/trunk/doc/regions.txt
brlcad/trunk/doc/rounding.txt
brlcad/trunk/doc/tool_categories.txt
Modified: brlcad/trunk/doc/CMakeLists.txt
===================================================================
--- brlcad/trunk/doc/CMakeLists.txt 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/CMakeLists.txt 2020-05-28 20:47:56 UTC (rev 75972)
@@ -14,31 +14,31 @@
)
set(documentation_DATA
+ BRL-CAD.bib
IDEAS
PROJECTS
- README.AIX
- README.BSD
- README.IRIX
- README.Linux
- README.MacOSX
- README.Solaris
- README.VAX
- README.Windows
- TODO.BREP
- TODO.shaded_displays
+ README/README.AIX
+ README/README.BSD
+ README/README.IRIX
+ README/README.Linux
+ README/README.MacOSX
+ README/README.Solaris
+ README/README.VAX
+ README/README.Windows
archer_ack.txt
- bu_opt_design_notes.txt
- brep.txt
- BRL-CAD.bib
checklist.txt
- cvs.txt
description.txt
- editors.txt
ged.tr
- history.txt
- hypot.txt
- mater.txt
- matrix.txt
+ notes/TODO.BREP
+ notes/TODO.shaded_displays
+ notes/brep.txt
+ notes/bu_opt_design_notes.txt
+ notes/cvs.txt
+ notes/editors.txt
+ notes/history.txt
+ notes/hypot.txt
+ notes/mater.txt
+ notes/matrix.txt
pre_BRL-CAD.bib
)
ADD_DOC(documentation_DATA ".")
@@ -209,12 +209,12 @@
mged/wm-prims.ps
mged/wm-tube.ps
mk.tr
+ notes/ecosystem.dot
+ notes/regions.txt
+ notes/rounding.txt
+ notes/tool_categories.txt
old-mged.tr
pkg.tr
- regions.txt
- rounding.txt
- tool_categories.txt
- ecosystem.dot
)
ADD_DOC(documentation_mged_old_DATA mged_old)
@@ -223,14 +223,14 @@
CMAKEFILES(
CMakeLists.txt
- README.OSCON-2014
+ README/README.OSCON-2014
STARTERS
STRATEGY
- bsd_semaphore_bug.txt
- cmake_vars.txt
- csv_to_comgeom.txt
- implicit_constraints.txt
- lcov.txt
+ notes/bsd_semaphore_bug.txt
+ notes/cmake_vars.txt
+ notes/csv_to_comgeom.txt
+ notes/implicit_constraints.txt
+ notes/lcov.txt
pad_file.xml.in
)
Copied: brlcad/trunk/doc/README/README.AIX (from rev 75971,
brlcad/trunk/doc/README.AIX)
===================================================================
--- brlcad/trunk/doc/README/README.AIX (rev 0)
+++ brlcad/trunk/doc/README/README.AIX 2020-05-28 20:47:56 UTC (rev 75972)
@@ -0,0 +1,35 @@
+BRL-CAD on AIX README
+=====================
+
+Dec. 15, 2011 - As of this date, it has been some time since an AIX
+build of BRL-CAD has been tested, and thus far it has NOT been tested
+b with the new CMake build system.
+
+Kitware provides an AIX powerpc binary for CMake, see
+http://www.cmake.org/cmake/resources/software.html
+
+
+Building BRL-CAD under AIX is fairly straightforward using a correctly
+installed version on the GCC compiler. If, however, you are using the
+IBM Visual Age compiler, then there are additional manual compilation
+steps that will be necessary. In particular, the IBM compiler and
+associated standard C library headers are inconsistent with respect to
+ANSI/POSIX compliance compiler options.
+
+The IBM compiler supports a variety of compliance options, the two of
+particular relevance to building BRL-CAD (in terms of being the close
+to obtaining a functional compile) are the strict compliance
+(-qlanglvl=stdc89) or "extended" compliance (-qlanglvl=extc89) modes.
+Problems encountered in our build environment using strict compliance
+does mostly work though we ran into errors in the standard C library
+headers.
+
+Using the "extended" compliance mode resolved the standard C library
+header issues, but introduces problems in the compilation of BRL-CAD
+as the compiler then disables the provision of the __STDC__
+preprocessor symbol. BRL-CAD then defaults back to K&R mode, which
+the compiler verbosely refuses to compile. The "quick fix" that has
+been used in the past is to simply swap the compiler between the two
+modes as when one fails (e.g. strict), the other usually succeeds
+(e.g. extended). Barring that working, you can use extended mode and
+define __STDC__ manually.
Copied: brlcad/trunk/doc/README/README.BSD (from rev 75971,
brlcad/trunk/doc/README.BSD)
===================================================================
--- brlcad/trunk/doc/README/README.BSD (rev 0)
+++ brlcad/trunk/doc/README/README.BSD 2020-05-28 20:47:56 UTC (rev 75972)
@@ -0,0 +1,16 @@
+BRL-CAD on BSD README
+=====================
+
+BRL-CAD is frequently compiled under various variants of
+BSD including FreeBSD, NetBSD, OpenBSD, and even the original
+4.3 BSD (though now rare) - FreeBSD is the most common BSD
+platform tested, not counting Mac OSX. See the README.VAX
+document for additional details that pertain to building
+BRL-CAD on a VAX running BSD.
+
+CMake binaries for *BSD operating systems are not distributed
+by Kitware, but should be available through standard *BSD
+packaging mechanisms. Failing that, CMake can be bootstrapped
+without much difficulty on most modern Unix-style platforms.
+
+BRL-CAD is included in the FreeBSD Ports system.
Copied: brlcad/trunk/doc/README/README.IRIX (from rev 75971,
brlcad/trunk/doc/README.IRIX)
===================================================================
--- brlcad/trunk/doc/README/README.IRIX (rev 0)
+++ brlcad/trunk/doc/README/README.IRIX 2020-05-28 20:47:56 UTC (rev 75972)
@@ -0,0 +1,51 @@
+BRL-CAD on IRIX README
+======================
+
+Building on IRIX is one of the most tricky platforms to support
+without installing up-to-date compilation tools. That said, the build
+has and should work just fine with either the MIPSPro or GCC
+compilers. The best performance is usually achieved with the MIPSPro
+compiler, whereas GCC will compile faster with less fuss.
+
+Kitware provides CMake binaries for IRIX64 platforms:
+http://www.cmake.org/cmake/resources/software.html
+
+
+Parallel building
+-----------------
+For parallel compilation on IRIX, the -P option enables parallel
+build mode and the PARALLEL environment variable sets the number
+of CPUs (default is two):
+
+PARALLEL=4 make -P
+
+
+Potential problems you may encounter
+------------------------------------
+
+Symptom: MIPSPro linker reports symbol(s) missing
+
+Description: There's a known bug in the MIPSpro linker involving
+rpaths that are too long (namely longer than 255 characters) so care
+should be taken to not compile in directories that are too deep. The
+way this bug is usually seen is that the build will fail during
+compilation where unresolved symbols are reported during linking,
+symbols that are correctly included in the libraries being linked.
+
+Workaround: It is usually sufficient to retry the compile from a
+shorter path. (e.g., /tmp instead of /some/deep/path/to/brlcad)
+
+---
+
+Symptom: GCC crashes during compilation with internal errors
+
+Description: Certain versions of the gcc compiler are known to crash
+with internal error messages, for example on src/mged/animedit.c, when
+using optimization flags (i.e. -O3).
+
+Workaround: Compile in whatever directory is failing with -O0 instead:
+ cd src/mged
+ sed -i "s/ -O3 / -O0 /g" CMakeFiles/mged.dir/flags.make
+ make
+ cd ../..
+ make
Copied: brlcad/trunk/doc/README/README.Linux (from rev 75971,
brlcad/trunk/doc/README.Linux)
===================================================================
--- brlcad/trunk/doc/README/README.Linux (rev 0)
+++ brlcad/trunk/doc/README/README.Linux 2020-05-28 20:47:56 UTC (rev
75972)
@@ -0,0 +1,128 @@
+BRL-CAD on Linux README
+=======================
+
+Below are installation and platform notes of relevance to particular
+Linux distributions.
+
+Table of Contents
+-----------------
+Parallel Builds
+64-bit Compile
+32-bit Compile
+Arch Linux
+Ubuntu/Debian
+PPC64 Linux
+
+Parallel Builds
+---------------
+BRL-CAD compilation can take advantage of multiple CPUs. With
+Make based builds, this is done using the "-j" flag - e.g. a
+six core machine will build faster using "make -j6" to utilize
+all cores.
+
+
+64-bit Compile (on a platform that defaults to 32-bit)
+--------------
+
+cmake ../brlcad -DBRLCAD_WORD_SIZE=32BIT
+
+32-bit Compile (on a platform that defaults to 64-bit)
+--------------
+
+cmake ../brlcad -DBRLCAD_WORD_SIZE=64BIT
+
+* Note that in both of the above situations you need both a compiler that
+works in the alternate mode and system libraries of the correct type.
+
+
+Arch Linux
+----------
+
+An example PKGBUILD and needed scripts are provided in misc/archlinux.
+Review and edit the PKGBUILD to suit your preferred configuration and
+build situation (e.g. building from a tarball vs building from SVN).
+Run `makepkg` in that directory to build the package.
+
+
+Ubuntu/Debian
+-------------
+
+Users of Ubuntu, Debian, and other similar packaging distributions of
+Linux will need to ensure that a few essentials are in place before
+you will be able to compile BRL-CAD.
+
+Following the build instructions in the INSTALL file. You will need:
+
+gcc (3+, e.g. 4.0.3)
+g++ (3+, e.g. 4.0.3)
+make (e.g. gnu make 3.8.0)
+cmake (2.8.8 or newer)
+
+All three of those have implicit dependencies on other packages.
+
+You will also want to make sure that you have the X11 development
+headers installed:
+
+ apt-get install xserver-xorg-dev libx11-dev libxi-dev libxext-dev
+
+Other development packages needed to build on Debian-based platforms:
+
+ for building the Tcl/Tk libraries: libfontconfig-dev
+
+ for OpenGL: libglu1-mesa-dev
+
+Note there is a supported Debian package generation script in file
+'sh/make_deb.sh' which can function only on a Debian or Ubuntu system.
+It can be used like so:
+
+ $ cd <BRL-CAD source directory>
+
+ # get help for the script:
+ $ ./sh/make_deb.sh
+
+ # create a binary package:
+ $ ./sh/make_deb.sh -b
+
+You can customize the script's cmake build options by modifying the
+file 'misc/debian/rules'. Note that the BRL-CAD source directory
+should be deleted and recreated for each new attempt at package
+generation.
+
+
+Redhat/Fedora
+-------------
+
+Development packages for building on Redhat/Fedora platforms:
+
+ yum install libX11-devel
+ yum install libXext-devel # optional
+ yum install libXi-devel # optional
+ yum install freetype-devel # optional
+ yum install fontconfig-devel # optional
+ yum install mesa-libGL-devel # optional
+
+To determine what particular version of Redhat or Fedora you are
+using, check these files:
+
+cat /etc/redhat-release
+cat /etc/fedora-release
+
+Note there is a supported rpm package generation script in file
+'sh/make_rpm.sh' which can only function on a Fedora or openSUSE
+system. It can be used like so:
+
+ $ cd <BRL-CAD source directory>
+
+ # create an rpm file:
+ $ ./sh/make_rpm.sh
+
+It is also possible to create an RPM package using CPack with the
+make package build target, on systems with the proper RPM tools.
+
+PPC64 Linux
+-----------
+
+If you happen to be installing on a ppc64 Linux system, the binaries
+may not resolve correctly without being installed first. Be sure to
+install before testing applications (i.e., even before running the
+benchmark or "make test").
Copied: brlcad/trunk/doc/README/README.MacOSX (from rev 75971,
brlcad/trunk/doc/README.MacOSX)
===================================================================
--- brlcad/trunk/doc/README/README.MacOSX (rev 0)
+++ brlcad/trunk/doc/README/README.MacOSX 2020-05-28 20:47:56 UTC (rev
75972)
@@ -0,0 +1,109 @@
+BRL-CAD on Max OS X README
+==========================
+
+Being that this is one of the newest architectures to be added and
+officially supported, there are some issues to keep in mind with the
+installation when building from the sources. Beyond the notes
+provided here, building on Mac OS X can generally be considered the
+same as the UNIX, BSD, and Linux platforms.
+
+Table of Contents
+-----------------
+ Introduction
+ Table of Contents
+ CMake
+ X11 Window Server
+ Supported Versions
+ Mac OS X 10.2
+ Parallel Builds
+ Bugs
+
+CMake
+-----------------
+Kitware provides Mac OSX compilations of CMake:
+
+http://www.cmake.org/cmake/resources/software.html
+
+
+X11 Window Server
+-----------------
+You'll need to install an X11 server if you would like to build Tk and
+have a graphical user interface. Apple's X11 is the recommended X
+Window Server, but XQuartz should work too and is often newer than the
+official Apple version: http://xquartz.macosforge.org
+
+Supported Versions
+------------------
+BRL-CAD is generally only "extensively" tested by the developers on
+the latest released version of Mac OS X. That is to say that
+although the BRL-CAD package should build on prior versions of the Mac
+OS X operating system, they are generally and eventually not
+maintained and will require additional effort to obtain a build.
+Compiling on 10.3 or 10.4 should complete successfully. Due to a
+variety of significant application programming interface issues in
+early releases of Mac OS X, versions prior to 10.2 are unsupported.
+
+Parallel Builds
+---------------
+As many workstation and server systems shipped by Apple are
+multiprocessor systems, you can enjoy the benefits of decreased
+compile times by utilizing the "-j" option to make. After running
+configure, run "make -j2" to build on a 2-processor system.
+
+Universal Builds
+----------------
+
+Universal builds have not been fully vetted due to how BRL-CAD
+serializes data to disk. BRL-CAD's CMake logic is not currently
+set up to support this type of build, but plans to in the future.
+
+CMake and Mac OSX
+-----------------
+
+On a default configuration, CMake has some problems performing parallel
+builds on OSX - typically this will manifest itself as a series of
+"too many open files" errors. So far, the way to work around this in
+OSX 10.5 is to set the following system control variables to 50,000:
+
+kern.maxfiles
+kern.maxfilesperproc
+
+(check the current values using "sysctl <variable>" on the command line)
+
+and up the maxfiles limit in /etc/launchd.conf:
+
+limit maxfiles 50000 unlimited
+
+This is not widely tested, and OSX has quite a few limit settings that
+may or may not apply (and may change from one version to the next.) As
+we get a better feel for various platforms we can assemble a table of
+required settings. Other programs have this issue as well, so searching
+online may prove fruitful.
+
+So far, if parallel building doesn't work due to the above issue a
+non-parallel build will still succeed. Another workaround is to build
+just subdirectories (e.g. src/other, doc, etc.) individually and then
+do a toplevel make in non-parallel mode to finalize the build.
+
+OpenSceneGraph and OSX
+----------------------
+For 32bit OSX builds of an X11+OpenSceneGraph BRL-CAD:
+cmake .. -DBRLCAD_BUNDLED_LIBS=BUNDLED -DBRLCAD_ENABLE_OSG=ON
+-DBRLCAD_REGEX=SYSTEM -DBRLCAD_WORD_SIZE=32BIT -DOSG_WINDOWING_SYSTEM=X11
+
+
+Tips
+----
+
+If you need to get information about your machine and OSX version, try
+these commands:
+
+sw_vers -productVersion
+uname -a
+
+Bugs
+----
+The only known bugs specific to Mac OS X are limitations of Tk or the
+X11 event handler that are generally outside of BRL-CAD's domain.
+Refer to BUGS for more general details on known bugs and reporting
+mechanisms.
Copied: brlcad/trunk/doc/README/README.OSCON-2014 (from rev 75971,
brlcad/trunk/doc/README.OSCON-2014)
===================================================================
--- brlcad/trunk/doc/README/README.OSCON-2014 (rev 0)
+++ brlcad/trunk/doc/README/README.OSCON-2014 2020-05-28 20:47:56 UTC (rev
75972)
@@ -0,0 +1,53 @@
+BRL-CAD: A Vibrant Open Source Model
+
++ intro
+
+ - speaker
+
+ - old vs. new (Rurel's joke about old farmer and his young farmhand)
+
++ overview
+
+ - history, players
+
+ Mike Muuss [author of ping]
+
+ - license
+
+ - languages (Ohloh stats)
+
++ important technical features
+
+ - database format
+
+ - tools
+
+ - libraries
+
+ - use of other FOSS libraries
+
+ - road map
+
++ other features
+
++ community
+
+ - players (Ohloh stats)
+
++ process
+
+ - Source Forge
+
+ - API changes
+
+ - deprecation policy
+
+ - release procedures
+
+ - version control
+
+ - bug tracking
+
+- policy
+
+- outreach
Copied: brlcad/trunk/doc/README/README.Solaris (from rev 75971,
brlcad/trunk/doc/README.Solaris)
===================================================================
--- brlcad/trunk/doc/README/README.Solaris (rev 0)
+++ brlcad/trunk/doc/README/README.Solaris 2020-05-28 20:47:56 UTC (rev
75972)
@@ -0,0 +1,61 @@
+BRL-CAD on Solaris README
+=========================
+In recent years, there have been a variety of Solaris-style operating
+systems that have appeared, following Sun's open-source release of
+OpenSolaris. OpenSolaris itself doesn't seem to be especially active, but
+another derivative system called OpenIndiana has appeared, based on the
+illumos kernel - the Solaris file will be the place to add any notes
+needed to build on such derivative systems, as well as Solaris proper.
+
+Kitware does not provide a pre-compiled binary for CMake on Solaris
+type systems. To bootstrap from the source code, try the following:
+
+(You probably want to use gmake and gcc/g++ for this...)
+
+1. Download the source from http://www.cmake.org/cmake/resources/software.html
+2. unzip the tarball: gunzip cmake-X.Y.Z.tar.gz
+3. open the tarball: tar -xvf cmake-X.Y.Z.tar
+4. cd cmake-X.Y.Z
+5. CXX=g++ ./bootstrap -prefix=/home/user/cmake-install (or your preferred
directory)
+6. gmake
+7. gmake install
+
+Then (if you installed to somewhere other than a system dir) add the
+bin directory to your path:
+
+csh: setenv PATH /home/user/cmake-install/bin:$PATH
+bash: export PATH=/home/user/cmake-install/bin:$PATH
+
+From there, you should be good to build BRL-CAD. The most recent tests
+of the Sun Studio compiler suggest that there are issues to resolve,
+so (unless you want to fix those issues, which would be welcome!) you
+probably want to use the GCC compiler suite to build BRL-CAD as well:
+
+CC=gcc CXX=g++ cmake ../brlcad
+
+If while compiling you encounter an error "Text relocation remains
+against symbol" along with some number of lines following, it usually
+means that the build has attempted to link a static system library
+into a shared library being compiled (e.g. attempting to link a system
+libz.a into the png library distributed in src/other/libpng being
+compiled as libpng.so). If this happens, it likely indicates a problem
+with the CMake build logic and should be reported as a bug - you may also
+need to install a shared version of the library. Another possibility
+would be to add -mipure-text to the linker flags.
+
+OpenIndiana
+-----------
+
+To build with gcc and CMake on OpenIndiana, you need to install the
+following packages:
+
+pkg install pkg:/developer/gcc-7
+pkg install pkg:/developer/build/cmake
+pkg install pkg:/developer/versioning/subversion
+pkg install pkg:/system/header
+pkg install pkg:/developer/lexer/flex
+
+(Note that gcc-7 building doesn't work as of 2017-08-23 - the above
+install list is a starting point, but the repo currently doesn't
+build and isn't close to building. It may be an older gcc would
+have better luck...)
Copied: brlcad/trunk/doc/README/README.VAX (from rev 75971,
brlcad/trunk/doc/README.VAX)
===================================================================
--- brlcad/trunk/doc/README/README.VAX (rev 0)
+++ brlcad/trunk/doc/README/README.VAX 2020-05-28 20:47:56 UTC (rev 75972)
@@ -0,0 +1,43 @@
+BRL-CAD on VAX README
+=====================
+
+One of the first systems to run BRL-CAD was the VAX. In particular, a
+VAX 11/780 named VGR is the baseline reference machine for the BRL-CAD
+Benchmark suite. Through the 80's and most of the 90's, BRL-CAD was
+compiled for and maintained on VGR running 4.3 BSD until the hardware
+was finally decommissioned.
+
+BRL-CAD has been successfully compiled for and run under the simh
+Computer History Simulation Project's VAX simulator. Using this
+simulator, it's feasible to install one of the BSD variants
+(e.g. NetBSD) and the GCC compiler.
+
+No one has tried bootstrapping CMake on a VAX simh NetBSD image yet, so it
+is not known what problems may occur - the basic bootstrap procedure is:
+
+1. Download the source from http://www.cmake.org/cmake/resources/software.html
+2. unzip the tarball: gunzip cmake-X.Y.Z.tar.gz
+3. open the tarball: tar -xvf cmake-X.Y.Z.tar
+4. cd cmake-X.Y.Z
+5. CXX=g++ ./bootstrap -prefix=/home/user/cmake-install (or your preferred
directory)
+6. gmake
+7. gmake install
+
+As of the last effort involved in compiling BRL-CAD under this
+environment (using GNU Autotools), there were a few steps
+necessary that included the following:
+
+ - Define the preprocessor symbol "vax".
+
+ - Disable compilation of libfft and sig. The FFT library builds
+ convolution kernels that are too large for the usual VAX memory
+ sizes.
+
+ - Compile against libm.a instead of libm.so. The shared object
+ library (at least under NetBSD) is buggy and will cause run-time
+ bus errors (i.e. rt will crash). With CMake, you might try:
+ -DM_LIBRARY=/usr/lib/libm.a
+
+After those steps, you should at least be able to perform a benchmark
+compilation (i.e. "make benchmark"), raytrace images, and obtain
+performance metrics.
Copied: brlcad/trunk/doc/README/README.Windows (from rev 75971,
brlcad/trunk/doc/README.Windows)
===================================================================
--- brlcad/trunk/doc/README/README.Windows (rev 0)
+++ brlcad/trunk/doc/README/README.Windows 2020-05-28 20:47:56 UTC (rev
75972)
@@ -0,0 +1,113 @@
+BRL-CAD on Windows README
+=========================
+
+The usual way to build BRL-CAD for Windows is to use the CMake build
+system generator and the Microsoft Visual Studio C++ (MSVC) compiler.
+Recent versions of both (as of this writing, MSVC 2013 and CMake
+2.8.12+) are recommended. If generating an installer, the Nullsoft
+Scriptable Install System (NSIS) tool is also required.
+
+In principle, BRL-CAD can be built using CMake and environments like
+Cygwin and/or Mingw/Msys, but the latter is largely untested and
+infrequently supported. Enhancements or bug reports are welcome.
+
+Visual Studio
+-------------
+
+=== Notes on Windows 10 with latest SDK ===
+Because Tk before 8.6.8 cannot be built with the latest Windows SDK
+(naming conflicts; see [1]), an earlier one (10.0.15063.0 is the
+last working version) is needed (available at [2]).
+
+Targets `tk`, `tkstub` and `libfb` need to be changed to use this SDK
+(right click on a target -> Configuration Properties -> General;
+select the SDK in Windows SDK Version).
+
+Compilation is then unchanged from the below.
+
+[1]: https://core.tcl.tk/tk/tktview?name=3d34589aa0
+[2]: https://developer.microsoft.com/en-us/windows/downloads/sdk-archive
+
+===========================================
+
+=== Notes on Visual Studio 14 2015 ===
+
+In order to build this version (required to build the Creo 3 converter)
+with CMake, you must ensure that Microsoft's "rc.exe" program is
+installed and findable by CMake.
+
+To install "rc.exe", run or re-run the Visual Studio installer and enable
+Visual C++ components and "Visual Studio Extensibility Tools Update 1" under
+the "Common Tools" section.
+
+The extensibility tools can become unselected by default in some
+configurations. Verify "rc.exe" is installed in:
+
+"C:\Program Files (x86)\Windows Kits\8.1\bin\x64"
+
+Add that directory to your "Path" user variable so CMake will be able to
+locate the rc executable.
+
+See:
+https://stackoverflow.com/questions/43847542/rc-exe-no-longer-found-in-vs-2015-command-prompt
+
+======================================
+
+
+To build with CMake and Visual Studio, the first step is to obtain the
+BRL-CAD sources and create a build directory. In principle, it is not
+*required* to have a separate build directory, but with Windows and
+Visual Studio this is the only tested configuration. Once those the
+sources are obtained and the build directory is created, run the CMake
+application and specify the source and build directories.
+
+Once CMake has the correct directory settings, select Configure. If
+this is the first time running Configure with this build directory,
+CMake will prompt you to select a generator. Look for your version of
+Visual Studio and select it. Configuration should now proceed.
+
+It is normal for configuration to be a long process on Windows. Once
+it is complete, you should see a list of red highlighted entries
+appear in the CMake interface. Change any settings that appear to
+need changing and press Configure again. The second pass should be
+shorter. If no new red lines appear, the configuration is complete.
+
+The final CMake step, after completing Configuration, is to select
+Generate to create Visual Studio project files in the build directory.
+Once this is done, you may quit CMake.
+
+Navigate to your build directory. You should see a BRLCAD solution
+file for Visual Studio. Double-click that file, and Visual Studio
+should launch. It will load the targets (a default configuration of
+BRL-CAD on Windows will generate over 800 of them) and a large list of
+targets will appear. To build everything look for a target named
+ALL_BUILD. Start compiling that target.
+
+Once compilation is successfully complete, you can find the compiled
+executables in a 'bin' directory in your build directory. For
+example, mged.exe would be in brlcad-svn-trunk\.build\Debug\bin if
+brlcad-svn-trunk\.build is the build directory specified to CMake and
+CMAKE_BUILD_TYPE was set to Debug.
+
+You may want to produce an NSIS installer. If so, locate a target
+named PACKAGE and run it. The end result should be an .exe file
+capable of installing BRL-CAD.
+
+MINGW (WORK IN PROGRESS - THIS DOES NOT YET WORK!!!)
+-----
+
+After installing the MINGW system, set up as follows:
+
+set path=%path%;"C:\Program Files (x86)\CMake\bin"
+set path=%path%;C:\MinGW\bin
+
+now make a build directory, and run CMake:
+
+cmake ..\brlcad -G "MinGW Makefiles" -DBRLCAD_BUNDLED_LIBS=BUNDLED
+
+mingw32-make
+
+Note that you don't want to do this from an msys prompt that has
+sh in the path. (ConEmu can make using the standard Windows command
+prompt a bit more tolerable: http://conemu.github.io)
+
Deleted: brlcad/trunk/doc/README.AIX
===================================================================
--- brlcad/trunk/doc/README.AIX 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.AIX 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,35 +0,0 @@
-BRL-CAD on AIX README
-=====================
-
-Dec. 15, 2011 - As of this date, it has been some time since an AIX
-build of BRL-CAD has been tested, and thus far it has NOT been tested
-b with the new CMake build system.
-
-Kitware provides an AIX powerpc binary for CMake, see
-http://www.cmake.org/cmake/resources/software.html
-
-
-Building BRL-CAD under AIX is fairly straightforward using a correctly
-installed version on the GCC compiler. If, however, you are using the
-IBM Visual Age compiler, then there are additional manual compilation
-steps that will be necessary. In particular, the IBM compiler and
-associated standard C library headers are inconsistent with respect to
-ANSI/POSIX compliance compiler options.
-
-The IBM compiler supports a variety of compliance options, the two of
-particular relevance to building BRL-CAD (in terms of being the close
-to obtaining a functional compile) are the strict compliance
-(-qlanglvl=stdc89) or "extended" compliance (-qlanglvl=extc89) modes.
-Problems encountered in our build environment using strict compliance
-does mostly work though we ran into errors in the standard C library
-headers.
-
-Using the "extended" compliance mode resolved the standard C library
-header issues, but introduces problems in the compilation of BRL-CAD
-as the compiler then disables the provision of the __STDC__
-preprocessor symbol. BRL-CAD then defaults back to K&R mode, which
-the compiler verbosely refuses to compile. The "quick fix" that has
-been used in the past is to simply swap the compiler between the two
-modes as when one fails (e.g. strict), the other usually succeeds
-(e.g. extended). Barring that working, you can use extended mode and
-define __STDC__ manually.
Deleted: brlcad/trunk/doc/README.BSD
===================================================================
--- brlcad/trunk/doc/README.BSD 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.BSD 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,16 +0,0 @@
-BRL-CAD on BSD README
-=====================
-
-BRL-CAD is frequently compiled under various variants of
-BSD including FreeBSD, NetBSD, OpenBSD, and even the original
-4.3 BSD (though now rare) - FreeBSD is the most common BSD
-platform tested, not counting Mac OSX. See the README.VAX
-document for additional details that pertain to building
-BRL-CAD on a VAX running BSD.
-
-CMake binaries for *BSD operating systems are not distributed
-by Kitware, but should be available through standard *BSD
-packaging mechanisms. Failing that, CMake can be bootstrapped
-without much difficulty on most modern Unix-style platforms.
-
-BRL-CAD is included in the FreeBSD Ports system.
Deleted: brlcad/trunk/doc/README.IRIX
===================================================================
--- brlcad/trunk/doc/README.IRIX 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.IRIX 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,51 +0,0 @@
-BRL-CAD on IRIX README
-======================
-
-Building on IRIX is one of the most tricky platforms to support
-without installing up-to-date compilation tools. That said, the build
-has and should work just fine with either the MIPSPro or GCC
-compilers. The best performance is usually achieved with the MIPSPro
-compiler, whereas GCC will compile faster with less fuss.
-
-Kitware provides CMake binaries for IRIX64 platforms:
-http://www.cmake.org/cmake/resources/software.html
-
-
-Parallel building
------------------
-For parallel compilation on IRIX, the -P option enables parallel
-build mode and the PARALLEL environment variable sets the number
-of CPUs (default is two):
-
-PARALLEL=4 make -P
-
-
-Potential problems you may encounter
-------------------------------------
-
-Symptom: MIPSPro linker reports symbol(s) missing
-
-Description: There's a known bug in the MIPSpro linker involving
-rpaths that are too long (namely longer than 255 characters) so care
-should be taken to not compile in directories that are too deep. The
-way this bug is usually seen is that the build will fail during
-compilation where unresolved symbols are reported during linking,
-symbols that are correctly included in the libraries being linked.
-
-Workaround: It is usually sufficient to retry the compile from a
-shorter path. (e.g., /tmp instead of /some/deep/path/to/brlcad)
-
----
-
-Symptom: GCC crashes during compilation with internal errors
-
-Description: Certain versions of the gcc compiler are known to crash
-with internal error messages, for example on src/mged/animedit.c, when
-using optimization flags (i.e. -O3).
-
-Workaround: Compile in whatever directory is failing with -O0 instead:
- cd src/mged
- sed -i "s/ -O3 / -O0 /g" CMakeFiles/mged.dir/flags.make
- make
- cd ../..
- make
Deleted: brlcad/trunk/doc/README.Linux
===================================================================
--- brlcad/trunk/doc/README.Linux 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.Linux 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,128 +0,0 @@
-BRL-CAD on Linux README
-=======================
-
-Below are installation and platform notes of relevance to particular
-Linux distributions.
-
-Table of Contents
------------------
-Parallel Builds
-64-bit Compile
-32-bit Compile
-Arch Linux
-Ubuntu/Debian
-PPC64 Linux
-
-Parallel Builds
----------------
-BRL-CAD compilation can take advantage of multiple CPUs. With
-Make based builds, this is done using the "-j" flag - e.g. a
-six core machine will build faster using "make -j6" to utilize
-all cores.
-
-
-64-bit Compile (on a platform that defaults to 32-bit)
---------------
-
-cmake ../brlcad -DBRLCAD_WORD_SIZE=32BIT
-
-32-bit Compile (on a platform that defaults to 64-bit)
---------------
-
-cmake ../brlcad -DBRLCAD_WORD_SIZE=64BIT
-
-* Note that in both of the above situations you need both a compiler that
-works in the alternate mode and system libraries of the correct type.
-
-
-Arch Linux
-----------
-
-An example PKGBUILD and needed scripts are provided in misc/archlinux.
-Review and edit the PKGBUILD to suit your preferred configuration and
-build situation (e.g. building from a tarball vs building from SVN).
-Run `makepkg` in that directory to build the package.
-
-
-Ubuntu/Debian
--------------
-
-Users of Ubuntu, Debian, and other similar packaging distributions of
-Linux will need to ensure that a few essentials are in place before
-you will be able to compile BRL-CAD.
-
-Following the build instructions in the INSTALL file. You will need:
-
-gcc (3+, e.g. 4.0.3)
-g++ (3+, e.g. 4.0.3)
-make (e.g. gnu make 3.8.0)
-cmake (2.8.8 or newer)
-
-All three of those have implicit dependencies on other packages.
-
-You will also want to make sure that you have the X11 development
-headers installed:
-
- apt-get install xserver-xorg-dev libx11-dev libxi-dev libxext-dev
-
-Other development packages needed to build on Debian-based platforms:
-
- for building the Tcl/Tk libraries: libfontconfig-dev
-
- for OpenGL: libglu1-mesa-dev
-
-Note there is a supported Debian package generation script in file
-'sh/make_deb.sh' which can function only on a Debian or Ubuntu system.
-It can be used like so:
-
- $ cd <BRL-CAD source directory>
-
- # get help for the script:
- $ ./sh/make_deb.sh
-
- # create a binary package:
- $ ./sh/make_deb.sh -b
-
-You can customize the script's cmake build options by modifying the
-file 'misc/debian/rules'. Note that the BRL-CAD source directory
-should be deleted and recreated for each new attempt at package
-generation.
-
-
-Redhat/Fedora
--------------
-
-Development packages for building on Redhat/Fedora platforms:
-
- yum install libX11-devel
- yum install libXext-devel # optional
- yum install libXi-devel # optional
- yum install freetype-devel # optional
- yum install fontconfig-devel # optional
- yum install mesa-libGL-devel # optional
-
-To determine what particular version of Redhat or Fedora you are
-using, check these files:
-
-cat /etc/redhat-release
-cat /etc/fedora-release
-
-Note there is a supported rpm package generation script in file
-'sh/make_rpm.sh' which can only function on a Fedora or openSUSE
-system. It can be used like so:
-
- $ cd <BRL-CAD source directory>
-
- # create an rpm file:
- $ ./sh/make_rpm.sh
-
-It is also possible to create an RPM package using CPack with the
-make package build target, on systems with the proper RPM tools.
-
-PPC64 Linux
------------
-
-If you happen to be installing on a ppc64 Linux system, the binaries
-may not resolve correctly without being installed first. Be sure to
-install before testing applications (i.e., even before running the
-benchmark or "make test").
Deleted: brlcad/trunk/doc/README.MacOSX
===================================================================
--- brlcad/trunk/doc/README.MacOSX 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.MacOSX 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,109 +0,0 @@
-BRL-CAD on Max OS X README
-==========================
-
-Being that this is one of the newest architectures to be added and
-officially supported, there are some issues to keep in mind with the
-installation when building from the sources. Beyond the notes
-provided here, building on Mac OS X can generally be considered the
-same as the UNIX, BSD, and Linux platforms.
-
-Table of Contents
------------------
- Introduction
- Table of Contents
- CMake
- X11 Window Server
- Supported Versions
- Mac OS X 10.2
- Parallel Builds
- Bugs
-
-CMake
------------------
-Kitware provides Mac OSX compilations of CMake:
-
-http://www.cmake.org/cmake/resources/software.html
-
-
-X11 Window Server
------------------
-You'll need to install an X11 server if you would like to build Tk and
-have a graphical user interface. Apple's X11 is the recommended X
-Window Server, but XQuartz should work too and is often newer than the
-official Apple version: http://xquartz.macosforge.org
-
-Supported Versions
-------------------
-BRL-CAD is generally only "extensively" tested by the developers on
-the latest released version of Mac OS X. That is to say that
-although the BRL-CAD package should build on prior versions of the Mac
-OS X operating system, they are generally and eventually not
-maintained and will require additional effort to obtain a build.
-Compiling on 10.3 or 10.4 should complete successfully. Due to a
-variety of significant application programming interface issues in
-early releases of Mac OS X, versions prior to 10.2 are unsupported.
-
-Parallel Builds
----------------
-As many workstation and server systems shipped by Apple are
-multiprocessor systems, you can enjoy the benefits of decreased
-compile times by utilizing the "-j" option to make. After running
-configure, run "make -j2" to build on a 2-processor system.
-
-Universal Builds
-----------------
-
-Universal builds have not been fully vetted due to how BRL-CAD
-serializes data to disk. BRL-CAD's CMake logic is not currently
-set up to support this type of build, but plans to in the future.
-
-CMake and Mac OSX
------------------
-
-On a default configuration, CMake has some problems performing parallel
-builds on OSX - typically this will manifest itself as a series of
-"too many open files" errors. So far, the way to work around this in
-OSX 10.5 is to set the following system control variables to 50,000:
-
-kern.maxfiles
-kern.maxfilesperproc
-
-(check the current values using "sysctl <variable>" on the command line)
-
-and up the maxfiles limit in /etc/launchd.conf:
-
-limit maxfiles 50000 unlimited
-
-This is not widely tested, and OSX has quite a few limit settings that
-may or may not apply (and may change from one version to the next.) As
-we get a better feel for various platforms we can assemble a table of
-required settings. Other programs have this issue as well, so searching
-online may prove fruitful.
-
-So far, if parallel building doesn't work due to the above issue a
-non-parallel build will still succeed. Another workaround is to build
-just subdirectories (e.g. src/other, doc, etc.) individually and then
-do a toplevel make in non-parallel mode to finalize the build.
-
-OpenSceneGraph and OSX
-----------------------
-For 32bit OSX builds of an X11+OpenSceneGraph BRL-CAD:
-cmake .. -DBRLCAD_BUNDLED_LIBS=BUNDLED -DBRLCAD_ENABLE_OSG=ON
--DBRLCAD_REGEX=SYSTEM -DBRLCAD_WORD_SIZE=32BIT -DOSG_WINDOWING_SYSTEM=X11
-
-
-Tips
-----
-
-If you need to get information about your machine and OSX version, try
-these commands:
-
-sw_vers -productVersion
-uname -a
-
-Bugs
-----
-The only known bugs specific to Mac OS X are limitations of Tk or the
-X11 event handler that are generally outside of BRL-CAD's domain.
-Refer to BUGS for more general details on known bugs and reporting
-mechanisms.
Deleted: brlcad/trunk/doc/README.OSCON-2014
===================================================================
--- brlcad/trunk/doc/README.OSCON-2014 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.OSCON-2014 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,53 +0,0 @@
-BRL-CAD: A Vibrant Open Source Model
-
-+ intro
-
- - speaker
-
- - old vs. new (Rurel's joke about old farmer and his young farmhand)
-
-+ overview
-
- - history, players
-
- Mike Muuss [author of ping]
-
- - license
-
- - languages (Ohloh stats)
-
-+ important technical features
-
- - database format
-
- - tools
-
- - libraries
-
- - use of other FOSS libraries
-
- - road map
-
-+ other features
-
-+ community
-
- - players (Ohloh stats)
-
-+ process
-
- - Source Forge
-
- - API changes
-
- - deprecation policy
-
- - release procedures
-
- - version control
-
- - bug tracking
-
-- policy
-
-- outreach
Deleted: brlcad/trunk/doc/README.Solaris
===================================================================
--- brlcad/trunk/doc/README.Solaris 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.Solaris 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,61 +0,0 @@
-BRL-CAD on Solaris README
-=========================
-In recent years, there have been a variety of Solaris-style operating
-systems that have appeared, following Sun's open-source release of
-OpenSolaris. OpenSolaris itself doesn't seem to be especially active, but
-another derivative system called OpenIndiana has appeared, based on the
-illumos kernel - the Solaris file will be the place to add any notes
-needed to build on such derivative systems, as well as Solaris proper.
-
-Kitware does not provide a pre-compiled binary for CMake on Solaris
-type systems. To bootstrap from the source code, try the following:
-
-(You probably want to use gmake and gcc/g++ for this...)
-
-1. Download the source from http://www.cmake.org/cmake/resources/software.html
-2. unzip the tarball: gunzip cmake-X.Y.Z.tar.gz
-3. open the tarball: tar -xvf cmake-X.Y.Z.tar
-4. cd cmake-X.Y.Z
-5. CXX=g++ ./bootstrap -prefix=/home/user/cmake-install (or your preferred
directory)
-6. gmake
-7. gmake install
-
-Then (if you installed to somewhere other than a system dir) add the
-bin directory to your path:
-
-csh: setenv PATH /home/user/cmake-install/bin:$PATH
-bash: export PATH=/home/user/cmake-install/bin:$PATH
-
-From there, you should be good to build BRL-CAD. The most recent tests
-of the Sun Studio compiler suggest that there are issues to resolve,
-so (unless you want to fix those issues, which would be welcome!) you
-probably want to use the GCC compiler suite to build BRL-CAD as well:
-
-CC=gcc CXX=g++ cmake ../brlcad
-
-If while compiling you encounter an error "Text relocation remains
-against symbol" along with some number of lines following, it usually
-means that the build has attempted to link a static system library
-into a shared library being compiled (e.g. attempting to link a system
-libz.a into the png library distributed in src/other/libpng being
-compiled as libpng.so). If this happens, it likely indicates a problem
-with the CMake build logic and should be reported as a bug - you may also
-need to install a shared version of the library. Another possibility
-would be to add -mipure-text to the linker flags.
-
-OpenIndiana
------------
-
-To build with gcc and CMake on OpenIndiana, you need to install the
-following packages:
-
-pkg install pkg:/developer/gcc-7
-pkg install pkg:/developer/build/cmake
-pkg install pkg:/developer/versioning/subversion
-pkg install pkg:/system/header
-pkg install pkg:/developer/lexer/flex
-
-(Note that gcc-7 building doesn't work as of 2017-08-23 - the above
-install list is a starting point, but the repo currently doesn't
-build and isn't close to building. It may be an older gcc would
-have better luck...)
Deleted: brlcad/trunk/doc/README.VAX
===================================================================
--- brlcad/trunk/doc/README.VAX 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.VAX 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,43 +0,0 @@
-BRL-CAD on VAX README
-=====================
-
-One of the first systems to run BRL-CAD was the VAX. In particular, a
-VAX 11/780 named VGR is the baseline reference machine for the BRL-CAD
-Benchmark suite. Through the 80's and most of the 90's, BRL-CAD was
-compiled for and maintained on VGR running 4.3 BSD until the hardware
-was finally decommissioned.
-
-BRL-CAD has been successfully compiled for and run under the simh
-Computer History Simulation Project's VAX simulator. Using this
-simulator, it's feasible to install one of the BSD variants
-(e.g. NetBSD) and the GCC compiler.
-
-No one has tried bootstrapping CMake on a VAX simh NetBSD image yet, so it
-is not known what problems may occur - the basic bootstrap procedure is:
-
-1. Download the source from http://www.cmake.org/cmake/resources/software.html
-2. unzip the tarball: gunzip cmake-X.Y.Z.tar.gz
-3. open the tarball: tar -xvf cmake-X.Y.Z.tar
-4. cd cmake-X.Y.Z
-5. CXX=g++ ./bootstrap -prefix=/home/user/cmake-install (or your preferred
directory)
-6. gmake
-7. gmake install
-
-As of the last effort involved in compiling BRL-CAD under this
-environment (using GNU Autotools), there were a few steps
-necessary that included the following:
-
- - Define the preprocessor symbol "vax".
-
- - Disable compilation of libfft and sig. The FFT library builds
- convolution kernels that are too large for the usual VAX memory
- sizes.
-
- - Compile against libm.a instead of libm.so. The shared object
- library (at least under NetBSD) is buggy and will cause run-time
- bus errors (i.e. rt will crash). With CMake, you might try:
- -DM_LIBRARY=/usr/lib/libm.a
-
-After those steps, you should at least be able to perform a benchmark
-compilation (i.e. "make benchmark"), raytrace images, and obtain
-performance metrics.
Deleted: brlcad/trunk/doc/README.Windows
===================================================================
--- brlcad/trunk/doc/README.Windows 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/README.Windows 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,113 +0,0 @@
-BRL-CAD on Windows README
-=========================
-
-The usual way to build BRL-CAD for Windows is to use the CMake build
-system generator and the Microsoft Visual Studio C++ (MSVC) compiler.
-Recent versions of both (as of this writing, MSVC 2013 and CMake
-2.8.12+) are recommended. If generating an installer, the Nullsoft
-Scriptable Install System (NSIS) tool is also required.
-
-In principle, BRL-CAD can be built using CMake and environments like
-Cygwin and/or Mingw/Msys, but the latter is largely untested and
-infrequently supported. Enhancements or bug reports are welcome.
-
-Visual Studio
--------------
-
-=== Notes on Windows 10 with latest SDK ===
-Because Tk before 8.6.8 cannot be built with the latest Windows SDK
-(naming conflicts; see [1]), an earlier one (10.0.15063.0 is the
-last working version) is needed (available at [2]).
-
-Targets `tk`, `tkstub` and `libfb` need to be changed to use this SDK
-(right click on a target -> Configuration Properties -> General;
-select the SDK in Windows SDK Version).
-
-Compilation is then unchanged from the below.
-
-[1]: https://core.tcl.tk/tk/tktview?name=3d34589aa0
-[2]: https://developer.microsoft.com/en-us/windows/downloads/sdk-archive
-
-===========================================
-
-=== Notes on Visual Studio 14 2015 ===
-
-In order to build this version (required to build the Creo 3 converter)
-with CMake, you must ensure that Microsoft's "rc.exe" program is
-installed and findable by CMake.
-
-To install "rc.exe", run or re-run the Visual Studio installer and enable
-Visual C++ components and "Visual Studio Extensibility Tools Update 1" under
-the "Common Tools" section.
-
-The extensibility tools can become unselected by default in some
-configurations. Verify "rc.exe" is installed in:
-
-"C:\Program Files (x86)\Windows Kits\8.1\bin\x64"
-
-Add that directory to your "Path" user variable so CMake will be able to
-locate the rc executable.
-
-See:
-https://stackoverflow.com/questions/43847542/rc-exe-no-longer-found-in-vs-2015-command-prompt
-
-======================================
-
-
-To build with CMake and Visual Studio, the first step is to obtain the
-BRL-CAD sources and create a build directory. In principle, it is not
-*required* to have a separate build directory, but with Windows and
-Visual Studio this is the only tested configuration. Once those the
-sources are obtained and the build directory is created, run the CMake
-application and specify the source and build directories.
-
-Once CMake has the correct directory settings, select Configure. If
-this is the first time running Configure with this build directory,
-CMake will prompt you to select a generator. Look for your version of
-Visual Studio and select it. Configuration should now proceed.
-
-It is normal for configuration to be a long process on Windows. Once
-it is complete, you should see a list of red highlighted entries
-appear in the CMake interface. Change any settings that appear to
-need changing and press Configure again. The second pass should be
-shorter. If no new red lines appear, the configuration is complete.
-
-The final CMake step, after completing Configuration, is to select
-Generate to create Visual Studio project files in the build directory.
-Once this is done, you may quit CMake.
-
-Navigate to your build directory. You should see a BRLCAD solution
-file for Visual Studio. Double-click that file, and Visual Studio
-should launch. It will load the targets (a default configuration of
-BRL-CAD on Windows will generate over 800 of them) and a large list of
-targets will appear. To build everything look for a target named
-ALL_BUILD. Start compiling that target.
-
-Once compilation is successfully complete, you can find the compiled
-executables in a 'bin' directory in your build directory. For
-example, mged.exe would be in brlcad-svn-trunk\.build\Debug\bin if
-brlcad-svn-trunk\.build is the build directory specified to CMake and
-CMAKE_BUILD_TYPE was set to Debug.
-
-You may want to produce an NSIS installer. If so, locate a target
-named PACKAGE and run it. The end result should be an .exe file
-capable of installing BRL-CAD.
-
-MINGW (WORK IN PROGRESS - THIS DOES NOT YET WORK!!!)
------
-
-After installing the MINGW system, set up as follows:
-
-set path=%path%;"C:\Program Files (x86)\CMake\bin"
-set path=%path%;C:\MinGW\bin
-
-now make a build directory, and run CMake:
-
-cmake ..\brlcad -G "MinGW Makefiles" -DBRLCAD_BUNDLED_LIBS=BUNDLED
-
-mingw32-make
-
-Note that you don't want to do this from an msys prompt that has
-sh in the path. (ConEmu can make using the standard Windows command
-prompt a bit more tolerable: http://conemu.github.io)
-
Deleted: brlcad/trunk/doc/TODO.BREP
===================================================================
--- brlcad/trunk/doc/TODO.BREP 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/TODO.BREP 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,304 +0,0 @@
-BREP TODO
-=========
-
-Included below is a basic work breakdown related to the implementation
-of boundary representation (BREP) support in BRL-CAD. Feel free to
-add to or expand this list and/or embellish it with additional
-information as appropriate. If you would like to work on the BREP
-implementation, send a note to the brlcad-devel mailing list.
-
-This file is a general scratch pad for categorizing and itemizing BREP
-implementation tasks. It is not an implementation plan.
-
-This is a work in progress.
-
-
-Geometry Entities
------------------
-
-point
-line (e.g., line segment, ray, bidirectionally infinite line)
-line set (e.g., polyline, polygon)
-curve (e.g., spline, arc, circle, ellipse)
-plane
-surface (e.g., spline, polygonal)
-surface+curve (i.e. a trimmed surface)
-solid
-
-
-Geometry Evaluation
--------------------
-
-point -> point
-point -> line
-point -> curve
-point -> plane
-point -> surface
-point -> surface+curve
-point -> solid
-
-line -> line
-line -> curve
-line -> plane
-line -> surface
-line -> surface+curve
-line -> solid
-
-curve -> curve
-curve -> plane
-curve -> surface
-curve -> surface+curve
-curve -> solid
-
-plane -> plane
-plane -> surface
-plane -> surface+curve
-plane -> solid
-
-surface -> surface
-surface -> surface+curve
-surface -> solid
-
-surface+curve -> surface+curve
-surface+curve -> solid
-
-solid -> solid
-
-
-Geometry Queries
-----------------
-
-[ geometric properties ]
-intersects
-inside
-outside
-on
-intersectionSet
-firstIntersectionSet
-closestDistance
-closestSet (e.g., closestPoint)
-booleanEvaluation
-insideSet (e.g., insideSolid, insideLoop (trimmed))
-outsideSet
-onSet
-
-[ parametric properties ]
-uvSpace <--> ImageSpace Mapping (for ALL primitive types)
-curvatures
-normalSet (e.g., normalVector, normalPlane)
-tangentSet (e.g., tangentVectors, tangentPlanes)
-
-[ checks ]
-isValid
-isSolid
-isManifold
-isFlat
-
-[ bounding volumes ]
-boundingBox
-boundingSphere
-
-
-Geometry Modifiers
-------------------
-
-scale
-rotate
-translate
-shear
-
-mirror
-copy/clone
-delete
-
-invertRepresentation
-evaluateBoolean (i.e. CSG)
-snapTogether (e.g., | -)
-
-sweep
-extrude
-revolve
-extend/stretch
-
-trim (e.g., cutting plane)
-split (i.e. copy and two trims)
-
-fillet
-chamfer
-
-
-Ray Tracing
------------
-
-intersectionSet query
- boundingBox
- line -> solid evaluation
-normalSet query
- line -> solid evaluation
-
-line->solid evaluation
- line->surface || line->plane
-
-line->plane
- line->line
-
-line->surface
- line->curve || line->line
- closestDistance
-
-closestDistance
- point->plane
- point->point
-
-line->curve
- line->point
-
-line->line
- line->point
-
-line->point
- point->point
-
-
-Interactive Visualization
--------------------------
-
-implicit primitive to solid conversion
-solid on solid CSG evaluation (i.e. unevaluated to evaluated BREP)
-solid tessellation
-
-
-Conversion
-----------
-
-3DM to BRL-CAD
-BRL-CAD to 3DM
-STEP to BRL-CAD
-IGES to BRL-CAD
-BRL-CAD to STEP
-BRL-CAD to IGES
-
-
-********************************************************************************
- Below are some thoughts and notes about specific issues related to the above
- topics - may be useful as comments at some point, or at least food for
thought.
-********************************************************************************
-
-/*
- * Point-Point Evaluation
- *
- * Answer Evaluation Questions involving two points:
- *
- * 1. Intersection - for a point, there are three possible categories of of
intersection:
- * * Identical - point values identical and all bound values identical
- *
- * * * * * * * * *
- * * *
- * * 1 2 *
- * * * *
- * * *
- * * *
- * * * * * * * * *
- *
- * * Contained - values not all identical but bounds of the point of
interest all smaller than bounds of
- * point it is being compared to
- *
- *
- * * * * * * * * * * * * * * * * * * *
* *
- * * 1 * *
*
- * * * * * * * * * * * * * *
*
- * * * * * * * 1 *
*
- * * * 2 * * * * *
*
- * * * * * * * 2 *
*
- * * * * * * * * * * * * * *
*
- * * * * * * * * * * * * * * * * * * *
* *
- *
- *
- * * Overlapping - values not all identical but bounds of the point of
interest all overlap bounds of
- * the point it is being compared to. (Note: a corner
case is when the value of the upper
- * bound of one point is equal to the lower bound of the
other - this is defined to be
- * overlapping.)
- *
- *
- * * * * * * * * * * * * * * * * *
* * * * * * * *
- * * * * *
* *
- * * 1 * * * * * * * * * * *
* * * * * * * * * *
- * * * * * * * * * * * * 1 * *
* * 1 * *
- * * * * * * * * *
* * * *
- * * * * * * * * * * * * * * * * * * *
* * 2 * *
- * * 2 * * 2 *
* * * * * * * * *
- * * * * *
* *
- * * * * * * * * * * * * * * * * * *
* * * * * * * * *
- *
- *
- * 2. Outside - "If the points are not identical in value and/or error
bounds, is the point of interest and its error
- * bounds contained or overlapping with the comparison point, or vice
versa? If not, the point of interest is
- * outside the comparison point.
- *
- * Contained and Overlapping points present a problem. Take the case
where two points have an overlapping bound
- * and a third point must decide its relationship with each of them:
- *
- * * * * * * * * *
- * * *
- * * 1 *
- * * *
- * * * * * * * * * * * * * * * * *
- * * * * * * *
- * * * * * * * * * * *
- * * 2 * * 3 *
- * * * * *
- * * * * *
- * * * * * * * * * * * * * * * * *
- *
- * Point 1 and Point 2 overlap and may intersect. When Point 3
evaluates its relationships with Point 1 and
- * Point 2, it finds that it overlaps and may intersect Point 1, but it
does NOT overlap Point 3. This means
- * that Point 1 may intersect Point 2 OR Point 3, but NOT both at the
same time. Any assumption of equality
- * involving any of these three points must decide how to handle this
situation, and the decision must be both
- * consistent and reproducible. The possible decisions are:
- *
- * 1 = 2, 1 != 3
- * 1 != 2, 1 = 3
- *
- * In order to have a concrete method for deciding this question, point
evaluation cannot be a local, two point
- * only test. It is necessary to search out all points which overlap
the two points in question (i.e. the only
- * points which might impact the decisions of which points are identical
in this particular case) and resolve the
- * question amongst all of them. One possibility would be to assemble
all the guaranteed non-equalities among
- * the set, search for the shortest distance between values among the
remaining possible relationships, and assign
- * intersection status based on those results. (This may not be
sufficient - bounding box size may also be
- * important.) For the original two points supplied, the question of
intersection or non-intersection is now
- * resolved as long as no geometry changes are made to any element that
has bounds overlapping their individual
- * bound.
- *
- * Once this near space evaluation is done, each point's list of
intersecting and non-intersecting points is updated.
- * A query routine with two points can first check the points' own
intersection/non-intersection lists to see if
- * the answer is already pre-determined. If it is not, determining via
the bounds inside/outside is straightforward
- * and deterministic and it cannot be intersecting.
- *
- * One question is what to do when the geometry DOES change. New
geometry may potentially change the decisions
- * on what is and is not intersecting - perhaps it should? Potential
trouble there with overlapping vs. non-
- * overlapping regions.
- */
-
-SOLID NURBS RAYTRACING ROBUSTNESS IMPROVEMENT/REFINEMENT
-
-One of the difficult tasks with solid raytracing is determining reliably when
we're inside or outside in cases where
-BRep edges don't exactly join up geometrically. OpenNURBS has tolerances
which define such shapes as "valid", but the
-mathematics of the ray interesection will still report wonky results once hit
points get inside those tolerance regions.
-
-We have resolution logic that tries to handle ambiguous cases, but one
potential technique we are not currently using
-would use the bounding box information from the NURBS prep trees to augment
that logic's robustness (or, more precisely,
-bound the portions of the ray segment within which point ambiguities need to
be resolved.)
-
-The current thought is to use the not-on-surface-point bounding box points
(which we can categorize as inside or outside
-relative to the surface they are bounding by construting vectors from on
surface points to those points and comparing
-them to the surface normal vectors) and the surface points themselves to
construct an outer and inner bounding volume
-for the BRep (to be reliable, we would also have to take care that we refine
enough to avoid self intersections in
-those volumes.) The overall bounding box of the outer volume should always be
larger than that of the inner volume,
-so a comparison of those would allow us to flip them if the "wrong" box is too
big to deal with a BRep with inverted
-surface normals. (Might actually also allow us to reliably detect and fix
such BReps, but that's a different topic.)
-
-Once we have the outer bounding volume, we intersect that along with the NURBS
BRep itself and use the ray segments
-from the outer bounding volume as bounding regions within which we resolve any
point ambiguities. This should allow
-us to "locally" resolve issues in such a way that doesn't accidentally flag
(say) a grazing corner hit as the in
-hit for a clean hit pair much further down the shotline (which will result in
a long "solid" segment through empty
-space.)
Deleted: brlcad/trunk/doc/TODO.shaded_displays
===================================================================
--- brlcad/trunk/doc/TODO.shaded_displays 2020-05-28 20:36:28 UTC (rev
75971)
+++ brlcad/trunk/doc/TODO.shaded_displays 2020-05-28 20:47:56 UTC (rev
75972)
@@ -1,122 +0,0 @@
-Consolidated from an e-mail thread and several e-mail messages by Sean
-to the BRL-CAD developers list in Jun 2013 which includes this message:
-
-https://sourceforge.net/mailarchive/forum.php?thread_name=02c584af-d1ad-4d23-9837-1412eed14350%40me.com&forum_name=brlcad-devel
-
-> 4. Finally we will get rid of wireframes. However, we will be able
-> to easily enable or disable shaded geometry or vice versa.
-
-We're not getting rid of wireframes. Shaded display geometry becoming
-the default, however, is already planned and in the works. NURBS
-surface-surface intersections (Wu's project) are required for that to
-happen.
-
-...
-
-Making wireframes not be the default is one of several reasons why
-we've been working on NURBS infrastructure. Not understanding why
-this is required given our representation format is usually an
-indication that someone does not yet understand the fundamental
-problem... which is not meant to be taken in a negative way. MOST
-people don't have experience with our particular problem domain which
-is specific to having mathematically-based implicit geometry
-representations along with boolean operations.
-
-When most people say shaded display, they usually think of OpenGL,
-Direct3D, games, other modeling systems, etc. Those systems are
-driven by polygons (triangles). To have that style of shaded display,
-you have to have polygons. We do not have polygons. We do not have a
-robust method for getting polygons. NURBS gives us a robust method.
-
-When we can 1) convert any geometry to NURBS, 2) evaluate any
-booleans, and 3) tessellate NURBS robustly, it will be possible to
-have robust shaded displays for all geometry. #1 was finished last
-year primarily thanks to Cliff and Wu. #3 was finished just this year
-primarily due to Keith. Work on #2 is underway and is scheduled to be
-finished this year..
-
-It's been a while since I've had to succinctly describe the problem
-and solution, so hopefully that is all understandable to everyone.
-There are several independent tasks that will need to be completed is
-anyone wants to help us get there more quickly. ;)
-
-...
-
-> Sean, are those tasks grouped somewhere in the TODO list, or?
-
-Not in such a succinct form because there is a lot of interrelation
-with other tasks/projects. E.g., one can frame reliable STEP NURBS
-import is just as important for shaded displays because users usually
-want to view their own existing data. Or once we have robust boolean
-evaluation of NURBS, most of our converters will need to be updated to
-use the new method ... that's a lot of work. :)
-
-Some tasks that come to mind related to shaded displays are:
-
-* library routine for boolean evaluation of NURBS
-
-* library routine for non-solid NURBS tessellation (capability exists,
- but not as formal API)
-
-* library routine for solid NURBS tessellation (capability exists, but
- not as formal API)
-
-* libgcv routine to perform NURBS boolean evaluation and tessellation
-
-* connecting "facetize" command to use libgcv (solid tessellation)
-
-* migrate current converter polygonal mesh boolean evaluation method
- of NMG-based converters to libgcv
-
-* updating all NMG-based exporters to use new libgcv routine, retain
- old method as legacy option
-
-* updating mged/archer to utilize boolean evaluated NURBS as a
- visualization mode
-
-Other useful but maybe not strictly necessary tasks:
-
-* optimize NURBS prep
-
-* connecting "E" and "ev" commands to use libgcv (non-solid or solid)
-
-* implement support for plate-mode NURBS
-
-* update STEP and 3DM converters to support non-solid NURBS import via
- plate-mode
-
-* libgcv routine to perform NURBS healing (close near-solid NURBS
- geometries)
-
-* update NURBS importers to with option to perform healing on import
-
-* update NURBS ray tracing to perform reparameterization/healing
- during prep
-
-* update IGES importer to import NURBS directly
-
-* implement OBJ NURBS import support
-
-* parallelize single-object NURBS prep (particularly the surface tree
- building)
-
-* parallelize boolean evaluation of NURBS
-
-* parallelize NURBS tessellation
-
-* refactor libdm API to better support (polygonal,curve,point) display
- lists
-
-* refactor libdm implementation to re-encapsulate platform-specific
- logic (no #ifdefs in public headers)
-
-* review old bspline NURBS logic, integrate useful portions, then
- remove the rest
-
-* formally document our BREP/NURBS primitive, capabilities and
- limitations
-
-That's just off the top of my head. There are undoubtedly other tasks
-involved but that's a partial list. Some/many of them are already in
-the TODO file, but many are not yet. Feel free to
-expand/incorporate/ignore. ;)
Deleted: brlcad/trunk/doc/brep.txt
===================================================================
--- brlcad/trunk/doc/brep.txt 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/brep.txt 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,223 +0,0 @@
-BRL-CAD Boundary-Representation Primitive
------------------------------------------
-
--- Introduction --
-
-This document describes the new Boundary-representation (BREP)
-primitive that has been implemented in BRL-CAD for use with external
-geometry import and improved visualisation.
-
-The primitive is not yet complete, and is currently quite buggy, so
-this document also serves to describe the current state of
-development, and the knowledge a developer needs to continue working
-on this primitive.
-
-
--- BREP Description --
-
-A boundary-representation is a method of representing solid geometry
-by describing its topology and corresponding geometry. In other words,
-the vertexes, edges, and faces as well as the points, curves, and
-surfaces belonging to those topological elements.
-
-For example, a cube has 8 vertexes each mapping to 1 point in space, 6
-faces each mapping to 1 surface, and 8 edges each shared by two faces
-and sharing its two vertexes with two other faces and owning 1 real
-curve.
-
-Actually creating/using a BREP requires keeping track of a lot of details,
-including everything mentioned above, plus curve / face orientations
-(a CCW edge/vertex ordering is usually used for determining front/back
-designations.)
-
-BRL-CAD has/had an existing BREP structure: the NMG (non-manifold
-geometry) primitive/library.
-
-[[describe reasons for not using the existing library]]
-
-One can use many types of surface and curve geometry, but generally a
-small subset are used by any particular implementation: e.g. having
-converted a few pieces of Pro/E through IGES to the new BRL-CAD BREP
-primitive, I've seen the following curve and surface types used:
-
-* Line
-* Arc
-* NURBS curve
-* Surface of revolution
-* NURBS surface
-
-The simple IGES converter used to import and test new geometry handles
-those types already. Other limitations of the converter are described
-later in the document.
-
-
--- Primitive Implementation --
-
-openNURBS was chosen to represent the geometry within BRL-CAD. This
-turned out to be a good and bad choice at the same time:
-
-* contains a lot of solid functionality
-* missing a lot of useful and important functionality
-
-In other words, the openNURBS API provided methods of functions for
-several pieces of functionality that had implementations removed when
-McNeil and Associates released openNURBS as essentially public domain
-code. This slowed development somewhat and meant the functionality had
-to be reimplemented by hand.
-
-The API is relatively straightforward C++, and it is used to evaluate
-geometry and represent/store BREPs in the BRL-CAD geometry file,
-through the built-in serialization facility (i.e. 3DM files).
-
-
--- Raytracing BREPs --
-
-See Abert et al. (raytracing 06 paper: Direct and Fast Ray Tracing of NURBS
-Surfaces).
-
-We use a two-dimensional root-finding technique: we represent the ray
-as two orthogonal planes (the intersection of the planes includes the
-ray), and then find the root of an equation that represents the
-gradient of the distance from the point to the intersection of the ray
-planes. When this gradient becomes zero (we found a root), we've also
-found the uv parameters for the intersection point.
-
-Newton iteration is used, mostly since it is simple, displays
-quadratic convergence when using good guesses, and is amenable to
-acceleration using SIMD instructions.
-
-Evaluation of the surface and its derivatives is done by the openNURBS
-library at this point. The Abert paper gives some information on how
-to do the evaluation using SIMD instructions (needed for speeding
-things up).
-
-A simple SIMD vector class has been implemented (see vector.h)
-supporting both SSE2 and FPU vector operations. This is currently only
-lightly used, since no optimization work has taken place yet
-(correctness before optimization).
-
-After intersection, we need to trim the surface. Every edge of a BREP
-is part of a loop "within" a face. Loops define boundaries on
-faces. In our cube example above, the four edges of a each face
-comprise a single loop (in this case an outer boundary). The surface
-may be defined as an infinite plane, but this outer boundary loop
-limits it to the area enclosed within those edges. As you may imagine,
-a face may have more than one loop and these additional loops will
-always be internal. All loops can also be considered trims, although
-this term seems to be reserved for actual geometric curves that are
-parameterized within the domain of an individual surface.
-
-Properly ray tracing a BREP is difficult (thus, the obvious
-explanation why this primitive is incomplete). There are several facts
-about BREPs that result in problematic situations during ray tracing:
-BREPs are not like implicit solid geometry: there is no nice equation
-to simply solve (a lot of numerical techniques are used); surfaces,
-curves and point geometry may not be aligned; there can be gaps
-between two mated surfaces... and the list goes on.
-
-Since it's possible to miss a surface but *need* a hit (i.e. it hit an
-edge but passed between surfaces that did not mate up or overlap), we
-need to do edge checks: at some point, we find out how far an
-intersection point or a ray is from some set of edges
-
-
--- Current Capabilities & Limitations --
-
-Developing a BRL-CAD primitive requires a minimum of 4 basic
-capabilities: reading from a geom db, writing to a geom db, providing
-a plot of the primitive (for MGED display), and handling shot
-intersection, which involves finding all intersections with the
-primitive and returning the results as a list of "segments" (these
-segments will later be used by BRL-CAD to do its boolean weaving).
-
-This primitive currently handles the first 3 capabilities fine, but
-has problems with the intersections (the most important part!)
-
-Issues:
-
-* bad acne (possibly caused by missing surfaces? duplicate
- intersections (making an odd number of hits along the ray), trimming
- errors?
-
-* problems with trimming (not completely sure the bezier clipping is
- correct)
-
-* possible problems with tolerances (been working with a very small
- (~2mm) object that has a moderate number of faces/edges)
-
-* no optimization, bad algorithms: bounding boxes (subsurface bounding
- boxes) should contain correct metadata concerning the need for
- trimming within the box, also a list of edges touched by the box for
- more efficient edge checking, evaluation optimization, etc...
-
-
-The current issue seems to be that we're missing surfaces altogether or
-getting extra intersections! or something funky is happening during
-trimming and edge checking. (BTW Pro/E seems to output overlapping
-surfaces, relying on the outer boundary loop to trim it - this implies
-that it should be quite difficult to actually miss both surfaces at an
-edge (since would have to get at least one intersection if they
-overlap at the edge!)
-
-[[ some pictures may be useful here ]]
-
-See all instances of "XXX" in the code (some may be out of date, but
-if something was fishy or I was being stupid/lazy/ignorant or some
-other bit of code was causing a problem, I tried to mark it with XXX.
-
-
--- Conceptual/Implementation Issues --
-
-model-space curve pullback to surface domain for trimming (introduces
-possible errors while trimming (i.e. at an edge it's possible both
-surfaces can be trimmed because of inaccuracies of sampling)...
-
-multiple intersections found
-
-handling edge/surface grazing consistently
-
-bezier conversion of nurbs curves for trimming
-
-subsurface bounding boxes: when subdividing a surface domain and
-testing for flatness, hard to create a perfect bounding box around the
-subdomain (i.e. such that all points on the surface lie within the
-bounding box.) For the most part this may not be a problem, but
-oblique shots cause problems here (an image would help). Either way,
-the problem of better fitting bounding boxes (without just arbitrarily
-increasing the size which would seriously affect performance) needs to
-be considered... currently attempting to sample an additional 5 points
-(instead of just the corners). This should serve to handle the current
-problem.
-
-Close-up axis aligned rendering of a cylinder from the circular ends
-produces a halo of spurious points. Ugh!
-
-Optimize for small objects (there are some fixed size adjustments in
-the bounding box/subsurface code).
-
-
--- IGES converter --
-
-A significant bit of time was spent writing the skeleton for a new
-IGES converter in order to get non-trivial BREP geometry from an
-external package into BRL-CAD for testing purposes (have been using
-the piston head part from one of the Pro/E tutorial models).
-
-I believe this converter can be made production-ready with some work:
-
-* polish options for output
-
-* handle assemblies and their proper mapping to BRL-CAD
-
-* handle naming? (don't know if IGES carries names, or if Pro/E adds
- them)
-
-* handle units properly!
-
-* tolerances when converting are still flaky (fix it) (cause BREP
- validity problems). Trims endpoint are not within zero tolerance
- (1e-12), so they "don't match" but they are very very close
- (1e-11)... so need to go through and call ON_Brep::CloseTrimGap() on
- each pair of trims in a loop.
-
-* Run lots of test cases!!!
Deleted: brlcad/trunk/doc/bsd_semaphore_bug.txt
===================================================================
--- brlcad/trunk/doc/bsd_semaphore_bug.txt 2020-05-28 20:36:28 UTC (rev
75971)
+++ brlcad/trunk/doc/bsd_semaphore_bug.txt 2020-05-28 20:47:56 UTC (rev
75972)
@@ -1,161 +0,0 @@
-The below backtraces were able to catch the infamous "fatal semaphore
-acquisition failure" bug on BSD. This is a bit tricky to catch in the act, so
-the below backtraces are added here to serve as references. They document both
-the gdb backtrace and the trick used to successfully attach to it it (a long
-sleep call compiled in to the key failure area prior to the run, allowing us to
-get a debugger on the program before it actually vanishes.) This case is most
-reliably seen when running make regress in parallel mode - it doesn't usually
-trigger when running individual programs interactively, although those do
-fail occasionally.
-
-So far this has only been observed on FreeBSD.
-
-Adjustment of the bombing message code reveals that the fatal error is
-EPERM - The current thread does not own the mutex.
-
-Maybe relevant (not sure if we have any code that might be using automatic
variables after thread_exit(), but the symptoms sound similar...) Only other
candidate I'm seeing is memory corruption of some sort...
-https://stackoverflow.com/a/7612070
-
-
-The first failure is from a GQA run:
-
-Architecture set to: x86_64--freebsd11.2.
-(lldb) bt
-* thread #1, name = 'gqa'
- * frame #0: 0x0000000817433f5c libthr.so.3`_umtx_op_err + 12
- frame #1: 0x000000081743056a
libthr.so.3`join_common(pthread=0x000000081ae18800,
thread_return=0x0000000000000000, abstime=0x0000000000000000) at thr_join.c:125
- frame #2: 0x0000000814b9b841
libbu.so.20`bu_parallel(func=(libged.so.20`plane_worker at gqa.c:1223),
ncpu=16, arg=0x00007fffffffe660) at parallel.c:722
- frame #3: 0x0000000800af161c libged.so.20`ged_gqa(gedp=0x000000081ae8d000,
argc=11, argv=0x000000081ae1c300) at gqa.c:2449
- frame #4: 0x00000000004010c3 gqa`main(argc=12, argv=0x00007fffffffe828) at
gqa.c:102
- frame #5: 0x0000000000400c05 gqa`_start + 149
-(lldb) thread list
-Process 56371 stopped
-* thread #1: tid = 101853, 0x0000000817433f5c libthr.so.3`_umtx_op_err + 12,
name = 'gqa'
- thread #2: tid = 100989, 0x000000081792e6da libc.so.7`__sys_nanosleep + 10,
name = 'gqa'
-(lldb) thread select 2
-* thread #2, name = 'gqa'
- frame #0: 0x000000081792e6da libc.so.7`__sys_nanosleep + 10
-libc.so.7`__sys_nanosleep:
--> 0x81792e6da <+10>: jb 0x8179a05a4 ; .cerror
- 0x81792e6e0 <+16>: retq
- 0x81792e6e1: int3
- 0x81792e6e2: int3
-(lldb) bt
-* thread #2, name = 'gqa'
- * frame #0: 0x000000081792e6da libc.so.7`__sys_nanosleep + 10
- frame #1: 0x0000000817428a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- frame #2: 0x00000008178b19eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- frame #3: 0x0000000814bb218c libbu.so.20`bu_semaphore_release(i=20) at
semaphore.c:272
- frame #4: 0x0000000800aebc31 libged.so.20`hit(ap=0x00007fffdd7f9dd8,
PartHeadp=0x00007fffdd7f97e8, segs=0x00007fffdd7f98e8) at gqa.c:1093
- frame #5: 0x0000000804062b12
librt.so.20`rt_shootray(ap=0x00007fffdd7f9dd8) at shoot.c:1273
- frame #6: 0x0000000800aec6cf libged.so.20`plane_worker(cpu=5,
ptr=0x00007fffffffe660) at gqa.c:1280
- frame #7: 0x0000000814b9bdcb
libbu.so.20`parallel_interface_arg(utd=0x000000081afedc80) at parallel.c:428
- frame #8: 0x0000000817426026
libthr.so.3`thread_start(curthread=0x000000081ae18800) at thr_create.c:290
-(lldb) up
-frame #1: 0x0000000817428a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- 284
- 285 curthread = _get_curthread();
- 286 _thr_cancel_enter(curthread);
--> 287 ret = __sys_nanosleep(time_to_sleep, time_remaining);
- 288 _thr_cancel_leave(curthread, 1);
- 289
- 290 return (ret);
-(lldb) up
-frame #2: 0x00000008178b19eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- 59
- 60 time_to_sleep.tv_sec = seconds;
- 61 time_to_sleep.tv_nsec = 0;
--> 62 if (((int (*)(const struct timespec *, struct timespec
*))
- 63 __libc_interposing[INTERPOS_nanosleep])(
- 64 &time_to_sleep, &time_remaining) != -1)
- 65 return (0);
-(lldb) up
-frame #3: 0x0000000814bb218c libbu.so.20`bu_semaphore_release(i=20) at
semaphore.c:272
- 269 # if defined(HAVE_PTHREAD_H)
- 270 if (pthread_mutex_unlock(&bu_semaphores[i].mu)) {
- 271 fprintf(stderr, "bu_semaphore_acquire():
pthread_mutex_unlock() failed on [%d]\n", i);
--> 272 sleep(60000);
- 273 bu_bomb("fatal semaphore acquisition failure");
- 274 }
- 275 # endif
-
-
-The second is from an rt raytrace of a bot:
-
-bin/rt".
-Architecture set to: x86_64--freebsd11.2.
-(lldb) bt
-* thread #1, name = 'rt'
- * frame #0: 0x0000000800861f5c libthr.so.3`_umtx_op_err + 12
- frame #1: 0x000000080085e56a
libthr.so.3`join_common(pthread=0x000000081aa3a400,
thread_return=0x0000000000000000, abstime=0x0000000000000000) at thr_join.c:125
- frame #2: 0x000000081455d841
libbu.so.20`bu_parallel(func=(librt.so.20`_db_walk_dispatcher at
db_tree.c:1955), ncpu=16, arg=0x00007fffffffd700) at parallel.c:722
- frame #3: 0x00000008032b0f8e
librt.so.20`db_walk_tree(dbip=0x000000081a861000, argc=1,
argv=0x00007fffffffe888, ncpu=16, init_state=0x00007fffffffd988,
reg_start_func=(librt.so.20`_rt_gettree_region_start at tree.c:109),
reg_end_func=(librt.so.20`_rt_gettree_region_end at tree.c:146),
leaf_func=(librt.so.20`_rt_gettree_leaf at tree.c:444),
client_data=0x00007fffffffd978) at db_tree.c:2199
- frame #4: 0x00000008036661d7
librt.so.20`rt_gettrees_muves(rtip=0x000000081a8a7000,
attrs=0x0000000000000000, argc=1, argv=0x00007fffffffe888, ncpus=16) at
tree.c:783
- frame #5: 0x0000000803669021
librt.so.20`rt_gettrees_and_attrs(rtip=0x000000081a8a7000,
attrs=0x0000000000000000, argc=1, argv=0x00007fffffffe888, ncpus=16) at
tree.c:887
- frame #6: 0x0000000803669142
librt.so.20`rt_gettrees(rtip=0x000000081a8a7000, argc=1,
argv=0x00007fffffffe888, ncpus=16) at tree.c:914
- frame #7: 0x0000000000406a00 rt`def_tree(rtip=0x000000081a8a7000) at
do.c:575
- frame #8: 0x000000000040bd52 rt`main(argc=6, argv=0x00007fffffffe860) at
main.c:495
- frame #9: 0x00000000004062e5 rt`_start + 149
-(lldb) thread list
-Process 7726 stopped
-* thread #1: tid = 100805, 0x0000000800861f5c libthr.so.3`_umtx_op_err + 12,
name = 'rt'
- thread #2: tid = 101797, 0x0000000816ec76da libc.so.7`__sys_nanosleep + 10,
name = 'rt'
-(lldb) thread select 2
-* thread #2, name = 'rt'
- frame #0: 0x0000000816ec76da libc.so.7`__sys_nanosleep + 10
-libc.so.7`__sys_nanosleep:
--> 0x816ec76da <+10>: jb 0x816f395a4 ; .cerror
- 0x816ec76e0 <+16>: retq
- 0x816ec76e1: int3
- 0x816ec76e2: int3
-(lldb) bt
-* thread #2, name = 'rt'
- * frame #0: 0x0000000816ec76da libc.so.7`__sys_nanosleep + 10
- frame #1: 0x0000000800856a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- frame #2: 0x0000000816e4a9eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- frame #3: 0x000000081457418c libbu.so.20`bu_semaphore_release(i=12) at
semaphore.c:272
- frame #4: 0x000000080366a193
librt.so.20`_rt_find_identical_solid(mat=0x0000000000000000,
dp=0x000000081a8a2e98, rtip=0x000000081a8a7000) at tree.c:425
- frame #5: 0x00000008036681e3
librt.so.20`_rt_gettree_leaf(tsp=0x000000081a9fa008, pathp=0x000000081a9fa150,
ip=0x00007fffd69eecc0, client_data=0x00007fffffffd978) at tree.c:491
- frame #6: 0x00000008032ae1b1
librt.so.20`db_recurse(tsp=0x000000081a9fa008, pathp=0x000000081a9fa150,
region_start_statepp=0x00007fffd69eef60, client_data=0x00007fffffffd978) at
db_tree.c:1170
- frame #7: 0x00000008032b35c9
librt.so.20`_db_walk_subtree(tp=0x000000081a81f200,
region_start_statepp=0x00007fffd69eef60,
leaf_func=(librt.so.20`_rt_gettree_leaf at tree.c:444),
client_data=0x00007fffffffd978, resp=0x000000000062e520) at db_tree.c:1898
- frame #8: 0x00000008032b172f librt.so.20`_db_walk_dispatcher(cpu=16,
arg=0x00007fffffffd700) at db_tree.c:1992
- frame #9: 0x000000081455ddcb
libbu.so.20`parallel_interface_arg(utd=0x000000081a9f85e0) at parallel.c:428
- frame #10: 0x0000000800854026
libthr.so.3`thread_start(curthread=0x000000081aa3a400) at thr_create.c:290
-(lldb) up
-frame #1: 0x0000000800856a2c
libthr.so.3`__thr_nanosleep(time_to_sleep=<unavailable>,
time_remaining=<unavailable>) at thr_syscalls.c:287
- 284
- 285 curthread = _get_curthread();
- 286 _thr_cancel_enter(curthread);
--> 287 ret = __sys_nanosleep(time_to_sleep, time_remaining);
- 288 _thr_cancel_leave(curthread, 1);
- 289
- 290 return (ret);
-(lldb) up
-frame #2: 0x0000000816e4a9eb libc.so.7`__sleep(seconds=60000) at sleep.c:62
- 59
- 60 time_to_sleep.tv_sec = seconds;
- 61 time_to_sleep.tv_nsec = 0;
--> 62 if (((int (*)(const struct timespec *, struct timespec
*))
- 63 __libc_interposing[INTERPOS_nanosleep])(
- 64 &time_to_sleep, &time_remaining) != -1)
- 65 return (0);
-(lldb) up
-frame #3: 0x000000081457418c libbu.so.20`bu_semaphore_release(i=12) at
semaphore.c:272
- 269 # if defined(HAVE_PTHREAD_H)
- 270 if (pthread_mutex_unlock(&bu_semaphores[i].mu)) {
- 271 fprintf(stderr, "bu_semaphore_acquire():
pthread_mutex_unlock() failed on [%d]\n", i);
--> 272 sleep(60000);
- 273 bu_bomb("fatal semaphore acquisition failure");
- 274 }
- 275 # endif
-(lldb) up
-frame #4: 0x000000080366a193
librt.so.20`_rt_find_identical_solid(mat=0x0000000000000000,
dp=0x000000081a8a2e98, rtip=0x000000081a8a7000) at tree.c:425
- 422 */
- 423 bu_semaphore_acquire(RT_SEM_STATS);
- 424 stp->st_bit = rtip->nsolids++;
--> 425 bu_semaphore_release(RT_SEM_STATS);
- 426
- 427 /*
- 428 * Fill in the last little bit of the structure in full
parallel
-(lldb)
-
Deleted: brlcad/trunk/doc/bu_opt_design_notes.txt
===================================================================
--- brlcad/trunk/doc/bu_opt_design_notes.txt 2020-05-28 20:36:28 UTC (rev
75971)
+++ brlcad/trunk/doc/bu_opt_design_notes.txt 2020-05-28 20:47:56 UTC (rev
75972)
@@ -1,97 +0,0 @@
-Thoughts on expansion of bu_opt capability to include subcommands, other misc
-notes...
-
-Check over POSIX.1-2008 Utility Conventions - should guide (but not define) our
-option handling. (In particular, we want long opts. On the other hand,
-probably explicitly don't want the full GNU 'opts anywhere' convention as that
-precludes structured subcommand parsing.)
-
-http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
-
-* Define separate structure for subcommands, have as an optional pointer in
- bu_opt structure.
-
-* Explore + and -+ as opt/longopt specifiers for subcommands, directly mapping
to
-- and -- for options. Use +- to denote the end of a subcommand, like -- denotes
-end of options.
-
-Rule - options with optional arguments (e.g. --help JSON vs --help - both are
-legal) will require that arguments needing to start with a "+" character (e.g.
---help "+arg1") be quoted. (For that matter, is the same true of normal "-"
-option parsing?)
-
-Can we allow "lazy" subcommand specification without +/-+ if we disqualify any
-string in quotes from being a subcommand? (e.g. 'cmd arg1 arg2' treats arg1 as
-a subcommand but 'cmd "arg1" arg2' treats arg1 as an arg? Do we need to worry
-about this at all?
-
-Can "leftover" operands from a subcommand be handed back up to parent commands?
-
-Convention thoughts:
-
-- or -- - option/long-option handling per POSIX and GNU convention.
-
-+ or -+ - explicit specifier of subcommand.
-
--- - explicit 'exit option parsing' mode - remainder is operands (per POSIX)
-except that a -+ option will indicate another subcommand or a +- will elevate
-the parsing environment back to the parent level.
-
-+- "exit subcommand" - returns parsing to the parent level command evaluation
-environment: brep -a1 -+plot -p1 +- -o out.pl results in brep handling -o
-out.pl, not plot.
-
-Scope of "next arg" other than +- is current command/subcommand: e.g. brep -a1
--+plot -p1 will pass p1 to plot's option handling, not brep's
-
-If subsequent -+ are specified, first check if the current command has the
-specified subcommand. If not, return parsing to the parent level to see if it
-has the specified subcommand, and so on until a command table claims the
-subcommand. Allows for both a subcommand of a subcommand:
-
-brep obj_csg.c -+bool_eval -+plot curve S1_S2
-
-and subsequent subcommands:
-brep obj_csg.c -+facetize -+simplify
-
-to be specified without requiring +- unless a command and a subcommand both
-have a matching subcommand.
-
-With that feature present, +- is necessary to specify a parent command's
version of
-the subcommand unambiguously (i.e. requires explicit exiting of subcommand
state with
-a matching subcommand):
-
-cmd arg1 +c +d -> runs d subcommand defined by c
-cmd arg1 +c +- +d -> runs d subcommand defined by cmd
-
-
-TODOs for bu_opt help routines:
-
-Maybe have help as a default subcommand rather than a default option, to allow
for fancy
-stuff without bastardizing the help option?
-
-* define a built-in bu_help to support docbook, json, etc. specification which
- can be used by commands not wanting to define their own, more complex
options.
-
-* need a routine to generate a POSIX compliant one-line description of the
- command's syntax
-
-* need built-in help (option or subcommand, maybe both?) that is available for
- commands not wanting to define their own help, but can be over-ridden by an
- explicit specification of help in the options. We will need some "smart"
help
- options for JSON, DocBook, etc as well as subcommand listing (--help cmds
- maybe?) so a calling script can systematically and automatically generate
- documentation for all commands.
-
-* explore the possibility of adding to the help system a generator of some sort
- that can produce a JSON structure describing the structure of the commands
and
- options in such a way that a libbu routine could accept that structure as a
- validation template and validate a command line string against it. Would
- (potentially) allow for things like smart tab completion, valid/invalid
syntax
- highlighting, etc. without having to either explicitly duplicate the command
- syntax in code or back such validation logic into each command. With this
- setup we would run the "generate syntax" help option for every
command/subcommand
- in all of BRL-CAD (which just coincidentally would make the function of the
- help system for every command in the code a build time requirement/check)
- and supply a pre-built validation database in a data_dir location for libbu
- to check.
Deleted: brlcad/trunk/doc/cmake_vars.txt
===================================================================
--- brlcad/trunk/doc/cmake_vars.txt 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/cmake_vars.txt 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,95 +0,0 @@
-# This is a worksheet to help with organizing our CMake options with
-# an eye towards consistency, clarity, and simplification.
-#
-# TODO:
-# * consistent naming convention
-# * eliminate aliases
-# * drop unnecessary/unhelpful/obsolete flags
-# * audit what ccmake presents by default
-#
-
-### HOW TO COMPILE ###
-
-CMAKE_BUILD_TYPE := Release | Debug
-
-BRLCAD_ENABLE_VERBOSE_PROGRESS "verbose output" OFF
-BRLCAD_ENABLE_COVERAGE "Build with coverage enabled" OFF
-
-ENABLE_ALL_CXX_COMPILE "Build all C and C++ files with a C++ compiler." OFF
- ENABLE_ALL_CXX
-
-BRLCAD_ENABLE_PROFILING
-BRLCAD_ENABLE_DTRACE "Build with dtrace support" OFF
-
-BRLCAD_ENABLE_SMP "Enable SMP architecture parallel computation support" ON
-BRLCAD_ENABLE_RUNTIME_DEBUG
- ENABLE_RUNTIME_DEBUG
- ENABLE_RUN_TIME_DEBUG
- ENABLE_RUNTIME_DEBUGGING
- ENABLE_RUN_TIME_DEBUGGING
-BRLCAD_FLAGS_DEBUG
- ENABLE_DEBUG
- ENABLE_FLAGS_DEBUG
- ENABLE_DEBUG_FLAGS
-BRLCAD_ENABLE_COMPILER_WARNINGS
- ENABLE_WARNINGS
- ENABLE_COMPILER_WARNINGS
-BRLCAD_ENABLE_STRICT
- ENABLE_STRICT
- ENABLE_STRICT_COMPILE
- ENABLE_STRICT_COMPILE_FLAGS
-
-
-### WHAT TO COMPILE ###
-
-BRLCAD_ENABLE_MINIMAL "Skip GUI support and docs. Faster builds." OFF
-BUILD_SHARED_LIBS "Build shared libraries" ON
-BUILD_STATIC_LIBS "Build static libraries" ON
-BRLCAD_ENABLE_BRLCAD_LIBRARY "Build the brlcad.dll" OFF
-
-BRLCAD_BUNDLED_LIBS := AUTO | BUNDLED | SYSTEM
- ENABLE_ALL
-
-BRLCAD_ENABLE_AQUA "Use Aqua instead of X11 whenever possible on OSX." OFF
-BRLCAD_ENABLE_X11 "Use X11." OFF
-BRLCAD_ENABLE_TK "Enable features requiring the Tk toolkit" ON
-BRLCAD_ENABLE_OPENGL "Enable support for OpenGL based Display Managers in
BRL-CAD." ON
- OFF "Disabled - NOT BRLCAD_ENABLE_X11 and NOT
BRLCAD_ENABLE_AQUA"
- ENABLE_OPENGL
-BRLCAD_ENABLE_QT "Enable features requiring Qt" OFF
-BRLCAD_ENABLE_OSG "Enable features requiring OpenSceneGraph" OFF
-
-BRLCAD_ENABLE_BULLET "Enable features requiring the Bullet Physics Library" ON
-BRLCAD_ENABLE_GCT "Enable features requiring GCT" ON
-BRLCAD_ENABLE_GDAL "Enable features requiring the Geospatial Data Abstraction
Library" ON
-BRLCAD_ENABLE_SPR "Enable features requiring Screened Poisson Surface
Reconstruction" OFF
-
-BRLCAD_ENABLE_BINARY_ATTRIBUTES "Enable support for binary attributes" OFF
-
-BRLCAD_ENABLE_OPENCL "Enable features requiring OpenCL" OFF
-
-BRLCAD_EXTRADOCS
- ENABLE_DOCS
- ENABLE_EXTRA_DOCS
- ENABLE_DOCBOOK
-BRLCAD_EXTRADOCS_VALIDATE "Perform validation for DocBook documentation" ON
-BRLCAD_EXTRADOCS_HTML "Build MAN page output from DocBook documentation" ON
-BRLCAD_EXTRADOCS_PHP "Build MAN page output from DocBook documentation" OFF
-BRLCAD_EXTRADOCS_PPT "Build MAN page output from DocBook documentation" ON
-BRLCAD_EXTRADOCS_MAN "Build MAN page output from DocBook documentation" ON
-BRLCAD_EXTRADOCS_PDF "Build PDF output from DocBook documentation" OFF
-BRLCAD_ENABLE_TARGETS "controls all DocBook based documentation. Keys off
what target level is enabled."
- EXTRADOCS_DEFAULT is ON when <= 2 ; OFF when > 2
-
-
-### HOW TO INSTALL ###
-
-BRLCAD_ENABLE_WIX
-BRLCAD_INSTALL_EXAMPLE_GEOMETRY "Install the example BRL-CAD geometry files."
ON
-
-# Local Variables:
-# tab-width: 8
-# mode: cmake
-# indent-tabs-mode: t
-# End:
-# ex: shiftwidth=2 tabstop=8
Deleted: brlcad/trunk/doc/csv_to_comgeom.txt
===================================================================
--- brlcad/trunk/doc/csv_to_comgeom.txt 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/csv_to_comgeom.txt 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,17 +0,0 @@
-These are some notes about using text manipulation tools to try taking the csv
-text files from GCI's transcription work and formatting them as comgeom files.
-I don't think they're fully working as yet, but certainly they are a starting
-point.
-
-tr "\r" "\n" < in_raw.csv > in.csv
-
-Solid table:
-
-awk -F, 'BEGIN {widthlist = "3 3 10 10 10 10 10 10 10"; split (widthlist,
widths, " ")}{for(i=1;i<=NF;i++){printf "%-*s", widths[i],$i};printf "\n"}'
in.csv
-
-Region table:
-awk -F, 'BEGIN {widthlist = "5 2 5 7 7 7 7 7 7 7 2 5 10"; split (widthlist,
widths, " ")}{for(i=1;i<=NF;i++){printf "%-*s", widths[i],$i};printf "\n"}'
in.csv
-
-Ident table:
-awk -F, 'BEGIN {widthlist = "10 10 10 43 3 3"; split (widthlist, widths, "
")}{for(i=1;i<=NF;i++){printf "%-*s", widths[i],$i};printf "\n"}' in.csv
-
Deleted: brlcad/trunk/doc/cvs.txt
===================================================================
--- brlcad/trunk/doc/cvs.txt 2020-05-28 20:36:28 UTC (rev 75971)
+++ brlcad/trunk/doc/cvs.txt 2020-05-28 20:47:56 UTC (rev 75972)
@@ -1,804 +0,0 @@
-BRL-CAD Concurrent Versions System Policy and Guidelines
-========================================================
-
-
-**********************************************************************
-NOTE: THESE INSTRUCTIONS ARE OUT-OF-DATE AS BRL-CAD NOW USES
-SUBVERSION INSTEAD OF CVS. CONSULT WITH CAUTION AS SOME PORTIONS ARE
-STILL RELEVANT BUT OTHERS THAT ARE CVS-SPECIFIC ARE NOT.
-**********************************************************************
-
-
-The document includes a set of requirements and recommended procedures
-for how to effectively use CVS with this project. Included are
-details on checking code in and out, effective use of commit messages,
-tag naming conventions, branch management, making releases, and more.
-Basic knowledge of CVS, its capabilities, and to a lesser extent its
-limitations are beyond the scope of this document. See the CVS
-website and the "References" section for more information. That said,
-the following general rules should always be adhered to:
-
-1. Code committed against HEAD should at least be tested and compile
- for the developer committing changes. "Don't break it."
-
-2. There is a STABLE branch that may only have code committed against
- it that a) compiles on all relevant platforms, b) does not
- detrimentally degrade performance, and c) runs correctly passing
- available validation tests.
-
-3. Branches should be used for experimental work that would otherwise
- leave HEAD in an inconsistent, non-compiling, or untestable state.
- Branches are not merged into HEAD until the code has been tested
- for correct and proper functionality.
-
-4. Commit and update frequently. Large or complicated changes should
- be broken up into smaller succinct commits as best possible to make
- reviewing easier. Commit working code early and commit often.
-
-5. Be consistent and informative. Tags need to follow a consistent
- naming convention. Commit messages need to be informative. Source
- code changes should follow existing style and be usefully
- commented.
-
-
-TABLE OF CONTENTS
------------------
- Introduction
- Table of Contents
- Overview
- Checking out sources
- from HEAD
- from STABLE
- from a branch/revision
- Checking in sources
- commit messages
- to HEAD
- to STABLE
- to a branch/revision
- Tag naming convention
- for releases
- for branches
- Making a release
- creating a maintenance branch
- applying release patches
- Merging a branch
- merging a branch into HEAD
- merging HEAD into a branch
- Making a branch
- Usage Tips
- References
-
-
-OVERVIEW
---------
-
- Code organizational sanity and consistency are of paramount
- importance. As CVS can both help and hinder efforts to keep the
- sources organized, the policy and guidelines outlined herein
- overview the manner in which CVS should be used with this project.
-
- This CVS policy and guidelines document should be used in
- combination with a developer's guide that covers other aspects of
- code contributions and developer behavior such as how and where to
- provide patches, what coding styles should be used, and how to
- make releases. Likewise, exact semantics of testing policy,
- requirements for migrating code from HEAD to STABLE, basic CVS
- usage, and release policy are outside the scope of this document.
-
- The intent of this document is to cover the broad aspects of how
- CVS is to be organized and used. This includes branch management,
- tag naming conventions, checking sources in and out, and other
- relevant usage policy.
-
- CVS branches should be used to separate out the various types of
- source code revisions. These include:
-
- 1) current or "active" sources
- 2) stable sources
- 3) releases
- 4) experimental sources
-
- The CVS HEAD is for active development. A separate STABLE branch
- exists to hold a revision of the sources that is validated and
- tested across platforms. Releases should only made off of stable
- revisions of the source code. When a release is made, a
- maintenance branch may and should exist for making patch releases.
- Finally, various experimental and developer undertakings that may
- benefit by being isolated from changes to HEAD or STABLE, or would
- likewise be disruptive to normal HEAD functionality, may live on
- a branch of their own.
-
- It's very important that the main CVS HEAD revision be a "mostly"
- stable code base so that at any given time users may download the
- latest sources, get the source code to compile with minimal
- effort, and have the core components mostly function as expected.
- See the "Checking in sources to HEAD" section for more details.
-
- Some users and developers will need from time to time to obtain a
- relatively recent version of the sources that is certain or at
- least expected to "work". This is what the STABLE branch is for.
- See the "Checking in sources to STABLE" section for more
- information.
-
-
-CHECKING OUT SOURCES
---------------------
-
- There are two basic ways to check out the sources: anonymously or
- as a developer. Developers have full read-write access to the
- source code. Anonymous users have read-only access; and the
- version of the sources checked out may actually lag the most
- recent commits by several hours.
-
- Regardless of whether the sources are being checked out by a
@@ Diff output truncated at 100000 characters. @@
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
_______________________________________________
BRL-CAD Source Commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
