2013/11/12 Stuart Henderson <[email protected]>: > - remove some a.out mentions > - adjust USE_LIBTOOL now that this is the default and talk about > CMake as well since this works in a similar way > - remove the outdated list of autoconf versions in the ports tree > and suggest that people use the version originally used in the distfile > > any comments? > > > > Index: specialtopics.html > =================================================================== > RCS file: /cvs/www/faq/ports/specialtopics.html,v > retrieving revision 1.31 > diff -u -p -r1.31 specialtopics.html > --- specialtopics.html 22 Jun 2013 09:58:46 -0000 1.31 > +++ specialtopics.html 12 Nov 2013 09:00:07 -0000 > @@ -109,9 +109,6 @@ Sometimes, it happens that a library is > internal functions happen to be visible to communicate between those files. > Those function names traditionally begin with an underscore, and are not > part of the API proper. > -<p> > -Note that the library naming scheme is ubiquitous on OpenBSD platforms, > -whether they be ELF or a.out. > > <h3>Tweaking ports builds to achieve the right names</h3> > Quite a few ports need tweaks to build shared libraries correctly anyways. > @@ -128,18 +125,23 @@ internal name, so you must link it with > <p> > On the other hand, remember that you can override <tt>Makefile</tt> > variables from > the command line, by using <tt>MAKE_FLAGS</tt> in the port's > <tt>Makefile</tt>. > -This is quite valuable in, for instance, libtool-based ports, which provide > -one such version variable for each library they create. > +In some cases, the program you're porting will have a simple variable which > +you can override by setting the library version in MAKE_FLAGS, for example > +<tt>MAKE_FLAGS= SO_VERSION=${LIBfoo_VERSION}</tt>. > +In others, the port will need to be patched to make use of such a variable. > > <p> > -The best way to handle libtool-based ports is to set > -<tt>USE_LIBTOOL=Yes</tt>. > -This activates the version of libtool in base, which handles most details > -automatically: > +The ports infrastructure already handles these details in libtool-based > +and CMake-based ports. > +For libtool, by default the version from the base OS is used, but in some > +cases this is insufficient and <tt>USE_LIBTOOL=gnu</tt> can be set. > +CMake is handled by using the <tt>cmake.port.mk</tt> module: > +<tt>MODULES += devel/cmake</tt>. > +In these cases, most details are handled automatically: > <ul> > - <li>libtool looks at <tt>SHARED_LIBS</tt> and automatically > - replaces version numbers. > - <li>libtool produces a log of shared library building in > + <li><tt>SHARED_LIBS</tt> is examined and version numbers are > + automatically replaced. > + <li>shared library building is logged in > <tt>${WRKBUILD}/shared_libs.log</tt> which can be directly > included in the port's <tt>Makefile</tt>. > </ul> > @@ -444,9 +446,9 @@ Which autoconf script actually gets call > environment variable <tt>AUTOCONF_VERSION</tt>. > Calling autoconf happens if you set <tt>CONFIGURE_STYLE=autoconf</tt>, > together with setting <tt>AUTOCONF_VERSION</tt>. > -Versions currently available are 2.13, 2.52, 2.54, 2.56, 2.57, 2.58, > -2.59, 2.60, 2.61, 2.62, 2.63, 2.64, 2.65, 2.67 and 2.68. > -These cover 99% of all configure scripts out there. > +In most cases, identify the version of autoconf that was used to generate > +the distributed configure script (usually obvious when reading the script) > +and use this same version yourself. > > <p> > autoconf relies on the standard unix preprocessor m4(1).
Reads fine for me. -- WBR, Vadim Zhukov
