On 11/15/15 10:02, Anthony J. Bentley wrote: > Hi, > > The GNU Autoconf Archive is a collection of more than 500 macros for GNU > Autoconf that have been contributed as free software by friendly supporters > of the cause from all over the Internet. > > I've encountered software in the wild (not yet in ports) that uses some > of the C++11 macros. > > ok? > That's 500 macros and from what I see there is not any testing in slight. These may work with gnu m4, how many work with m4?
How many of the macros have been tested to work with m4, more importantly which do not work with m4 and why? There are no patches, no exclusions. There are reference to specific autoconf versions, which autoconf versions can use these macros? AX_VAR_TIMEZONE_EXTERNALS, AX_FUNC_WHICH_GETHOSTBYNAME_R, and AX_PTHREAD have been updated to conform with Autoconf 2.68 If restricted to specific version then a conflict needs adding, only likely to be a few so might want to consider sub-packages for those with conflicts. A clue in Makefile about testing, if none is possible NO_TEST =.... "In contrast to what autoconf does, aclocal takes its macro files from the /usr/share/aclocal path, where most software installs them, and copies the macro files where they are defined directly inside aclocal.m4, appending them to one another. Then autoconf reads the file as if it was part of its macros' library. " In other words, the fact you don't see the individual macro doesn't mean it isn't there. (Note /usr/share/aclocal is /usr/local/share/aclocal Many ports include the required macros from the autoconf archive in the source tar ball already like these ./third_party/fontconfig/src/m4/ax_cc_for_build.m4 ./third_party/fontconfig/src/m4/ax_pthread.m4 ./third_party/fontconfig/src/m4/ax_create_stdint_h.m4 That leaves the reason for having these macros available might be just to create a source tar ball. In which case how many use OpenBSD to create a source tar ball, of those how many would use autoconf tools as their choice, then how many are using the autoconf archive, all under GPLv3+. There is a difference between building ports, and what's required for creating distributions. If you look in git repositories like github, the tar ball created automatically is not the same as the tar ball distributed, they have some process for creating the distribution tar ball and including just those autoconf archive macros required, so doing a git clone of github project, and building within the clone you might need the autoconf archive, this is not about building ports. If this does go forward there should be no build/runtime dependency on this port or very restricted use. If your missing something from the autoconf archive building a port from the tar ball it's an upstream issue in many cases. If your building a port by taking some snapshot tar ball from github then you need to add what's missing from a proper distribution tar ball. Don't confuse needing autoconf archive macros with building with the wrong source tar ball. automake/autoconf you run make dist to create the distribution, only needing autoconf archive if creating/recreating a aclocal.m4. Make this clear in the port. Checking for autoconfig archive macros, we have $ pkglocate /ax_ gnome-common-3.18.0:x11/gnome/common:/usr/local/share/aclocal/ax_check_enable_debug.m4 gnome-common-3.18.0:x11/gnome/common:/usr/local/share/aclocal/ax_code_coverage.m4 So you have a conflict with the port x11/gnome/common $ pwd ~/Downloads/autoconf-archive $ egrep "ax_code_coverage|ax_check_enable_debug" pkg/PLIST share/aclocal/ax_check_enable_debug.m4 share/aclocal/ax_code_coverage.m4 Needs resolving as could break building GNOME in bulk builds. Haven't checked what has a BDEP, LDEP on x11/gnome/common. My CVS ports tree is current, still an issue.... $ cd x11/gnome/common $ grep "/ax_" pkg/PLIST share/aclocal/ax_check_enable_debug.m4 share/aclocal/ax_code_coverage.m4
