[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Rick Taylor]

[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Thomas Petazzoni]

Dear Rick Taylor,

On Thu, 17 Jul 2014 09:36:16 +0000, Rick Taylor wrote:
> From 017be6459b46388f9377d00c2f48e838ec3ff98b Mon Sep 17 00:00:00 2001
> From: Rick Taylor <rick.taylor@cassidian.com>
> Date: Thu, 17 Jul 2014 10:04:10 +0100
> Subject: [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package
> 
> Signed-off-by: Rick Taylor <rick.taylor@cassidian.com>
> ---
>  package/pkg-autotools.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks for the patch. Could you detail a bit the use case you have for
$$($$(PKG)_AUTORECONF_ENV) ?

Also, an update to docs/manual/adding-packages-autotools.txt is needed
to take into account this new variable in the documentation.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Thomas De Schampheleire]

Hi Rick,

On Fri, Jul 18, 2014 at 10:29 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Rick Taylor,
>
> On Fri, 18 Jul 2014 08:21:34 +0000, Rick Taylor wrote:
>
>> Unfortunately I am stuck on a machine with no outgoing SMTP server on
>> the network.
>
> Not even GMail's one? That's usually how most people workaround stupid
> company restrictions.

Indeed.
If there is a proxy, you may need to set up a socat tunnel, see
http://lists.busybox.net/pipermail/buildroot/2014-June/099502.html

Best regards,
Thomas

[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Thomas Petazzoni]

Dear Rick Taylor,

On Fri, 18 Jul 2014 08:21:34 +0000, Rick Taylor wrote:

> Unfortunately I am stuck on a machine with no outgoing SMTP server on
> the network.

Not even GMail's one? That's usually how most people workaround stupid
company restrictions.

> I have the git patches, but I as I'm using a webmail client I have to
> work out exactly what is needed in the body of the email.

Most likely, your webmail client will screw up the patch if you paste
it in the body of the e-mail. That's why we really suggest people to
use git send-email.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Rick Taylor]

Hi Thomas,

Unfortunately I am stuck on a machine with no outgoing SMTP server on the network.  I have the git patches, but I as I'm using a webmail client I have to work out exactly what is needed in the body of the email.

Do you want content of both patch files as plain text in the body of the email?  If so, what do you want the subject line to be?

I'll update the documentation text to be a little clearer, I just cut'n'pasted from the LIBFOO_MAKE_ENV text in the same file.

Sorry to be a pain,

Rick Taylor
________________________________________
From: Thomas Petazzoni [thomas.petazzoni at free-electrons.com]
Sent: 17 July 2014 19:43
To: Rick Taylor
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

Dear Rick Taylor,

On Thu, 17 Jul 2014 12:21:54 +0000, Rick Taylor wrote:

> I haven't aggressively tested it against buildroot master I'm afraid
> as we have a load of extra infrastructure around buildroot so we
> stick to full releases, and we are just evaluating 2014.05.
>
> I shall update the docs/manual/adding-packages-autotools.txt and
> resubmit the patches.

Thanks for the explanation. However, we have received this e-mail with
a "PATCH 1/1" title even though it doesn't contain a patch, and then
the documentation update as PATCH 2/2.

In a nutshell, assuming you have a branch named "autoreconf-env" with
two patches on top of the "master" branch, what you should do to send
your patches is:

        git format-patch master

Then review the 0001-<foo>.patch and 0002-<bar>.patch to make sure
everything is in order. And then:

        git send-email --to buildroot at uclibc.org *.patch

Thanks,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Thomas Petazzoni]

Dear Rick Taylor,

On Thu, 17 Jul 2014 12:21:54 +0000, Rick Taylor wrote:

> I haven't aggressively tested it against buildroot master I'm afraid
> as we have a load of extra infrastructure around buildroot so we
> stick to full releases, and we are just evaluating 2014.05.
> 
> I shall update the docs/manual/adding-packages-autotools.txt and
> resubmit the patches.

Thanks for the explanation. However, we have received this e-mail with
a "PATCH 1/1" title even though it doesn't contain a patch, and then
the documentation update as PATCH 2/2.

In a nutshell, assuming you have a branch named "autoreconf-env" with
two patches on top of the "master" branch, what you should do to send
your patches is:

	git format-patch master

Then review the 0001-<foo>.patch and 0002-<bar>.patch to make sure
everything is in order. And then:

	git send-email --to buildroot at uclibc.org *.patch

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] Add $$(PKG)_AUTORECONF_ENV argument to autotools package

[Rick Taylor]

Hi Thomas,

Thank you for your prompt reply, I was unsure whether I had formatted the patch correctly in the email.

In house, we use a little M4 magic in our configure.ac files to insert subversion version numbers into the AC_INIT stanza of our libraries:

AC_INIT(libfoo,[1.0.]m4_esyscmd([if test "x$SVN_SITE" != "x"; then svn info $SVN_SITE -rHEAD | grep '^Last Changed Rev: ' | awk '{printf "%s",$4}'; else svnversion -n | sed 's/:/-/'; fi]))

Because of the way autotools works, the m4_esyscmd() is only executed when the autoreconf tool is run, not just autoconf.

Because we use an environment variable in the script, we need some mechanism of ensuring it is set correctly when autoreconf is run by buildroot, by putting the following in libfoo.mk:

LIBFOO_VERSION = HEAD
LIBFOO_SOURCE = libfoo-$(LIBFOO_VERSION).tar.gz
LIBFOO_SITE = http://svn_url/foo
LIBFOO_SITE_METHOD = svn
LIBFOO_AUTORECONF = YES
LIBFOO_AUTORECONF_ENV = SVN_SITE=$(LIBFOO_SITE)
$(eval $(autotools-package))

I hope that's clear?

I'm not sure how useful other people will find this, but we have been using it heavily since version 2013.08.

I haven't aggressively tested it against buildroot master I'm afraid as we have a load of extra infrastructure around buildroot so we stick to full releases, and we are just evaluating 2014.05.

I shall update the docs/manual/adding-packages-autotools.txt and resubmit the patches.

Many thanks,

Rick Taylor