On Tue, Nov 12, 2013 at 10:55 AM, Vadim Zhukov <[email protected]> wrote: > 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.
ok for me too. ciao, David
