Re: NEW: devel/autoconf-archive

[Anthony J. Bentley]

Hi Nigel,

You've convinced me that this probably shouldn't go into the tree.

Nigel Taylor writes:
> 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.

Unfortunately, this is a common problem on Github: they tend *not* to
provide dist tarballs, and they don't keep generated configure scripts
in Git. So you have no choice but to fetch the autogenerated "tarballs"
of the source using GH_*, and run autoconf yourself. Yet another example
of bad upstream behavior that we have to push against to keep our
sanity...

-- 
Anthony J. Bentley

Re: NEW: devel/autoconf-archive

[Jérémie Courrèges-Anglas]

"Anthony J. Bentley"  writes:

> Hi Nigel,

Hi folks,

> You've convinced me that this probably shouldn't go into the tree.
>
> Nigel Taylor writes:
>> 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.
>
> Unfortunately, this is a common problem on Github: they tend *not* to
> provide dist tarballs, and they don't keep generated configure scripts
> in Git. So you have no choice but to fetch the autogenerated "tarballs"
> of the source using GH_*, and run autoconf yourself. Yet another example
> of bad upstream behavior that we have to push against to keep our
> sanity...

This doesn't prevent the inclusion of such a port.  Having this archive
at hand could be useful for reference, instead of having to browse the
website.  Hence why I proposed to install the macros in a directory not
searched by default by autotools.

I'll admit that this usefulness is limited; your call. :)
-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: NEW: devel/autoconf-archive

[Nigel Taylor]

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

Re: NEW: devel/autoconf-archive

[Anthony J. Bentley]

Hi Jérémie,

Jérémie Courrèges-Anglas writes:
> If we install those macros in share/aclocal, then they will be available
> directly via autoreconf and friends, right?  I'm not sure whether it is
> desirable, it's a lot of code and autotools are already ugly enough...
> Do you know of other OSes which packages those macros in a directly
> reachable directory?  What about installing them in another dir?

share/aclocal is the default directory. FreeBSD and Debian use it for
their autoconf-archive package as well.

-- 
Anthony J. Bentley

NEW: devel/autoconf-archive

[Anthony J. Bentley]

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?

-- 
Anthony J. Bentley


autoconf-archive.tar.gz
Description: autoconf-archive.tar.gz

Re: NEW: devel/autoconf-archive

[Marc Espie]

On Sun, Nov 15, 2015 at 06:30:48PM +0100, Jérémie Courrèges-Anglas wrote:
> "Anthony J. Bentley"  writes:
> 
> > Hi,
> 
> 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?
> 
> If we install those macros in share/aclocal, then they will be available
> directly via autoreconf and friends, right?  I'm not sure whether it is
> desirable, it's a lot of code and autotools are already ugly enough...
> Do you know of other OSes which packages those macros in a directly
> reachable directory?  What about installing them in another dir?
> 
> Maybe I'm being paranoid here, *shrug*.

Precedent here is that we should wait until there is actual need. Like,
when you have software in the wild that moves to ports, then this will be
the time to consider this.

Re: NEW: devel/autoconf-archive

[Jérémie Courrèges-Anglas]

"Anthony J. Bentley"  writes:

> Hi,

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?

If we install those macros in share/aclocal, then they will be available
directly via autoreconf and friends, right?  I'm not sure whether it is
desirable, it's a lot of code and autotools are already ugly enough...
Do you know of other OSes which packages those macros in a directly
reachable directory?  What about installing them in another dir?

Maybe I'm being paranoid here, *shrug*.
-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE