[PATCH v2 0/2] move autoconf-archive into OE-core

[PATCH v2 0/2] move autoconf-archive into OE-core

[Patrick Ohly]

V2:
 - removed the gnome-common dependency that was still in V1
 - merged the .inc file into the .bb file and cleaned up the recipe

Patrick Ohly (2):
  autoconf-archive: move from meta-oe to OE-core
  autoconf-archive: simplify and fix recipe

 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb

base-commit: d3a41fbd94462efc8c6f1b55f6fb54001b447c45
-- 
git-series 0.9.1

[PATCH v2 1/2] autoconf-archive: move from meta-oe to OE-core

[Patrick Ohly]

Having common macros in OE-core that are needed by autotools based
projects makes sense. For example, tpm2.0-tools in meta-measured
depended on meta-oe only because of autoconf-archive.

This is a verbatim copy of the autoconf-archive recipe in
meta-openembedded rev 1cbd1bc1, with just one change: the patch which
disabled the installation of ax_code_coverage.m4 and
ax_check_enable_debug.m4 and the dependency on gnome-common were
removed.

So now autoconf-archive in OE-core provides them. gnome-common in
meta-oe will be changed to not install them and instead depend on
autoconf-archive.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc           | 13 +++++++++++++
 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 13 +++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
 create mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb

diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
new file mode 100644
index 0000000..4f63e0f
--- /dev/null
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
@@ -0,0 +1,13 @@
+LICENSE = "GPLv3"
+HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/"
+SECTION = "devel"
+
+DEPENDS += "m4-native"
+DEPENDS_class-native = "m4-native gnu-config-native"
+DEPENDS_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
+
+RDEPENDS_${PN} = "m4 gnu-config"
+
+SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
+
+inherit autotools
diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
new file mode 100644
index 0000000..0a1a771
--- /dev/null
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
@@ -0,0 +1,13 @@
+require autoconf-archive.inc
+
+
+PARALLEL_MAKE = ""
+
+LICENSE = "GPLv2 & GPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
+
+SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
+SRC_URI[sha256sum] = "e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
+
+EXTRA_OECONF += "ac_cv_path_M4=m4"
+BBCLASSEXTEND = "native nativesdk"
-- 
git-series 0.9.1

[PATCH v2 2/2] autoconf-archive: simplify and fix recipe

[Patrick Ohly]

The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3. There is
also the COPYING.EXCEPTION file with the autotools exception, which
gets ignored here in the recipe to keep it simpler.

All of the explicit dependencies seem unnecessary, and RDEPENDS_${PN}
doesn't do anything for native recipes either, so all of that gets
removed.

It also built fine without the m4 and parallel build workarounds.

There's no need to have a separate .inc file.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc           | 13 -------------
 meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 14 +++++++-------
 2 files changed, 7 insertions(+), 20 deletions(-)
 delete mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc

diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
deleted file mode 100644
index 4f63e0f..0000000
--- a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
+++ /dev/null
@@ -1,13 +0,0 @@
-LICENSE = "GPLv3"
-HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/"
-SECTION = "devel"
-
-DEPENDS += "m4-native"
-DEPENDS_class-native = "m4-native gnu-config-native"
-DEPENDS_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
-
-RDEPENDS_${PN} = "m4 gnu-config"
-
-SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
-
-inherit autotools
diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
index 0a1a771..d77c37d 100644
--- a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
+++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
@@ -1,13 +1,13 @@
-require autoconf-archive.inc
-
-
-PARALLEL_MAKE = ""
-
-LICENSE = "GPLv2 & GPLv3"
+SUMMARY = "a collection of freely re-usable Autoconf macros"
+HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/"
+SECTION = "devel"
+LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
+SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
 SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
 SRC_URI[sha256sum] = "e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
 
-EXTRA_OECONF += "ac_cv_path_M4=m4"
+inherit autotools
+
 BBCLASSEXTEND = "native nativesdk"
-- 
git-series 0.9.1

Re: [PATCH v2 2/2] autoconf-archive: simplify and fix recipe

[Khem Raj]

On Fri, Jul 28, 2017 at 7:49 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3. There is
> also the COPYING.EXCEPTION file with the autotools exception, which
> gets ignored here in the recipe to keep it simpler.
>
> All of the explicit dependencies seem unnecessary, and RDEPENDS_${PN}
> doesn't do anything for native recipes either, so all of that gets
> removed.
>
> It also built fine without the m4 and parallel build workarounds.
>
> There's no need to have a separate .inc file.
>
> Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
> ---
>  meta/recipes-devtools/autoconf-archive/autoconf-archive.inc           | 13 -------------
>  meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb | 14 +++++++-------
>  2 files changed, 7 insertions(+), 20 deletions(-)
>  delete mode 100644 meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
>
> diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc b/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
> deleted file mode 100644
> index 4f63e0f..0000000
> --- a/meta/recipes-devtools/autoconf-archive/autoconf-archive.inc
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -LICENSE = "GPLv3"
> -HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/"
> -SECTION = "devel"
> -
> -DEPENDS += "m4-native"
> -DEPENDS_class-native = "m4-native gnu-config-native"
> -DEPENDS_class-nativesdk = "m4-nativesdk gnu-config-nativesdk"
> -
> -RDEPENDS_${PN} = "m4 gnu-config"
> -
> -SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
> -
> -inherit autotools
> diff --git a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
> index 0a1a771..d77c37d 100644
> --- a/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
> +++ b/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb
> @@ -1,13 +1,13 @@
> -require autoconf-archive.inc
> -
> -
> -PARALLEL_MAKE = ""
> -
> -LICENSE = "GPLv2 & GPLv3"
> +SUMMARY = "a collection of freely re-usable Autoconf macros"
> +HOMEPAGE = "http://www.gnu.org/software/autoconf-archive/"
> +SECTION = "devel"
> +LICENSE = "GPLv3"

Perhaps  GPL-3.0-with-autoconf-exception would be more accurate here.

>  LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>
> +SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
>  SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
>  SRC_URI[sha256sum] = "e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
>
> -EXTRA_OECONF += "ac_cv_path_M4=m4"
> +inherit autotools
> +
>  BBCLASSEXTEND = "native nativesdk"
> --
> git-series 0.9.1
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH v2 2/2] autoconf-archive: simplify and fix recipe

[Patrick Ohly]

On Fri, 2017-07-28 at 09:44 -0700, Khem Raj wrote:
> On Fri, Jul 28, 2017 at 7:49 AM, Patrick Ohly <patrick.ohly@intel.com
> > +LICENSE = "GPLv3"
> 
> Perhaps  GPL-3.0-with-autoconf-exception would be more accurate here.

I wasn't sure whether such a thing existed already, but yes, as it does
it could be used here, with COPYING.EXCEPTION added as second
LIC_FILES_CHKSUM entry. I didn't want to be that fancy, but I can also
do a v3 with that change.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: [PATCH v2 2/2] autoconf-archive: simplify and fix recipe

[Khem Raj]

On Fri, Jul 28, 2017 at 11:43 AM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> On Fri, 2017-07-28 at 09:44 -0700, Khem Raj wrote:
>> On Fri, Jul 28, 2017 at 7:49 AM, Patrick Ohly <patrick.ohly@intel.com
>> > +LICENSE = "GPLv3"
>>
>> Perhaps  GPL-3.0-with-autoconf-exception would be more accurate here.
>
> I wasn't sure whether such a thing existed already, but yes, as it does
> it could be used here, with COPYING.EXCEPTION added as second
> LIC_FILES_CHKSUM entry. I didn't want to be that fancy, but I can also
> do a v3 with that change.

yes please. Its important from compliance perspective, and compliance is
never fancy :)

>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.



>
>