[Buildroot] [PATCH 1/2] package/libzip: add host variant

[Buildroot] [PATCH 1/2] package/libzip: add host variant

[Jörg Krause]

The updated host mfgtool package needs the host variant of libzip.

Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
 package/libzip/libzip.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/libzip/libzip.mk b/package/libzip/libzip.mk
index b90ea76f5e..280ca6d8c7 100644
--- a/package/libzip/libzip.mk
+++ b/package/libzip/libzip.mk
@@ -11,6 +11,7 @@ LIBZIP_LICENSE = BSD-3-Clause
 LIBZIP_LICENSE_FILES = LICENSE
 LIBZIP_INSTALL_STAGING = YES
 LIBZIP_DEPENDENCIES = zlib
+HOST_LIBZIP_DEPENDENCIES = host-zlib
 
 ifeq ($(BR2_PACKAGE_BZIP2),y)
 LIBZIP_DEPENDENCIES += bzip2
@@ -33,3 +34,4 @@ LIBZIP_CONF_OPTS += -DENABLE_OPENSSL=OFF
 endif
 
 $(eval $(cmake-package))
+$(eval $(host-cmake-package))
-- 
2.21.0

[Buildroot] [PATCH 2/2] package/mfgtools: bump to version 1.2.91

[Jörg Krause]

The version 0.02 was a pre-release and is dated from Nov 20, 2017.

Meanwhile:
 * the repo owner switch to NXPmicro
 * latest version is 1.12.91
 * the build system is CMake
 * the license is BSD-3 only

Note, that mfgtools uses git to define a version string `GIT_VERSION`.
It does so even when building from the provided source tarball. The
problem is, that git provides the version information of Buildroot.

To fix this, we patch the logic to retrieve the git version so it does
not run git for mfgtools. Unfortunately, this breaks the build process
because of the missing `gitversion.h` header file. Therefore, we add a
post configure hook which generates this file with the correct version
string.

Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
 .../0001-Fix-version-generation.patch         | 38 +++++++++++++++++++
 package/mfgtools/mfgtools.hash                |  5 +--
 package/mfgtools/mfgtools.mk                  | 35 ++++++-----------
 3 files changed, 51 insertions(+), 27 deletions(-)
 create mode 100644 package/mfgtools/0001-Fix-version-generation.patch

diff --git a/package/mfgtools/0001-Fix-version-generation.patch b/package/mfgtools/0001-Fix-version-generation.patch
new file mode 100644
index 0000000000..ca48c522ab
--- /dev/null
+++ b/package/mfgtools/0001-Fix-version-generation.patch
@@ -0,0 +1,38 @@
+From af9704ca3b7b02503f8ade069a77203869f0bcfa Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=B6rg=20Krause?= <joerg.krause@embedded.rocks>
+Date: Tue, 30 Apr 2019 15:51:47 +0200
+Subject: [PATCH] Fix version generation
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+mfgtools uses git to extract its own version number.
+
+This is an issue as the git-extracted version is conflicting when a top
+level project, e.g. a package manager, itself is a git repository.
+
+Since these git calls are legitimate only if git is used for the mfgtools
+subtree only, this patch adds a check: A .git directory has to exist at
+the root of the project to enable git-extracted version string.
+
+Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
+---
+ libuuu/gen_ver.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libuuu/gen_ver.sh b/libuuu/gen_ver.sh
+index d4e8c1b..bcc04a2 100755
+--- a/libuuu/gen_ver.sh
++++ b/libuuu/gen_ver.sh
+@@ -13,7 +13,7 @@ else
+ fi
+ 
+ # Test if we are in a repo
+-if [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ];
++if [ -d .git ] && [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ];
+ then
+ 	#echo "In a repo"
+ 	# Get the version of the last commit of the repo
+-- 
+2.21.0
+
diff --git a/package/mfgtools/mfgtools.hash b/package/mfgtools/mfgtools.hash
index 4932a80dba..4db97e6ae2 100644
--- a/package/mfgtools/mfgtools.hash
+++ b/package/mfgtools/mfgtools.hash
@@ -1,4 +1,3 @@
 # locally computed
-sha256  055d71227d18883d6e8bc9e854c076015f9a7749820a94272e19071bf0b25c89  mfgtools-v0.02.tar.gz
-sha256  2655559a6bb1179eae514f5c7166f4ede4f2453efa9cf4dc3c045cab5d57dede  LICENSE
-sha256  0963b6e5086bf454265b0f57821a02b681d1211e40ad74c310231cb4d94815c9  README.txt
+sha256  378caa930fdc1b06d49abf26811827f12103d995438b91302a7c6e34368419f9  mfgtools-uuu_1.2.91.tar.gz
+sha256  cc8d47f7b9260f6669ecd41c24554c552f17581d81ee8fc602c6d23edb8bf495  LICENSE
diff --git a/package/mfgtools/mfgtools.mk b/package/mfgtools/mfgtools.mk
index e4663a8af9..c42b18d43b 100644
--- a/package/mfgtools/mfgtools.mk
+++ b/package/mfgtools/mfgtools.mk
@@ -4,31 +4,18 @@
 #
 ################################################################################
 
-MFGTOOLS_VERSION = v0.02
-MFGTOOLS_SITE = $(call github,codeauroraforum,mfgtools,$(MFGTOOLS_VERSION))
-MFGTOOLS_SUBDIR = MfgToolLib
-MFGTOOLS_LICENSE = BSD-3-Clause or CPOL
-MFGTOOLS_LICENSE_FILES = LICENSE README.txt
-HOST_MFGTOOLS_DEPENDENCIES = host-libusb
+MFGTOOLS_VERSION = uuu_1.2.91
+MFGTOOLS_SITE = $(call github,NXPmicro,mfgtools,$(MFGTOOLS_VERSION))
+MFGTOOLS_LICENSE = BSD-3-Clause
+MFGTOOLS_LICENSE_FILES = LICENSE
+HOST_MFGTOOLS_DEPENDENCIES = host-libusb host-libzip host-zlib
 
-HOST_MFGTOOLS_CFLAGS = \
-	$(HOST_CFLAGS) $(HOST_LDFLAGS) -std=c++11 -lpthread \
-	-L$(@D)/MfgToolLib -lMfgToolLib -I$(@D)/MfgToolLib \
-	-lusb-1.0 -I$(HOST_DIR)/include/libusb-1.0 \
-	-fpermissive -Wno-write-strings
-
-define HOST_MFGTOOLS_CLI_BUILD
-	$(HOST_CONFIGURE_OPTS) $(MAKE) CC="$(HOSTCXX)" \
-		CFLAGS="$(HOST_MFGTOOLS_CFLAGS)" -C $(@D)/TestPrgm
-endef
-
-HOST_MFGTOOLS_POST_BUILD_HOOKS += HOST_MFGTOOLS_CLI_BUILD
-
-define HOST_MFGTOOLS_INSTALL_CMDS
-	$(INSTALL) -D -m 755 $(@D)/MfgToolLib/libMfgToolLib.so \
-		$(HOST_DIR)/lib/libMfgToolLib.so
-	$(INSTALL) -D -m 755 $(@D)/TestPrgm/mfgtoolcli \
-		$(HOST_DIR)/bin/mfgtoolcli
+# Version string generation is broken in mfgtools as it relies on git, even
+# when building from a source tarball. We patch gen_ver.sh to prevent defining
+# the GIT_VERSION in the build step and define GIT_VERSION ourself.
+define MFGTOOLS_SET_VERSION
+	echo '#define GIT_VERSION "lib$(MFGTOOLS_VERSION)"' > $(@D)/libuuu/gitversion.h
 endef
+HOST_MFGTOOLS_POST_CONFIGURE_HOOKS += MFGTOOLS_SET_VERSION
 
 $(eval $(host-cmake-package))
-- 
2.21.0

[Buildroot] [PATCH 2/2] package/mfgtools: bump to version 1.2.91

[Arnout Vandecappelle]

On 30/04/2019 22:11, J?rg Krause wrote:
> The version 0.02 was a pre-release and is dated from Nov 20, 2017.
> 
> Meanwhile:
>  * the repo owner switch to NXPmicro
>  * latest version is 1.12.91
>  * the build system is CMake
>  * the license is BSD-3 only
> 
> Note, that mfgtools uses git to define a version string `GIT_VERSION`.
> It does so even when building from the provided source tarball.

 Is there an upstream-provided tarball? If so, why do you use the github helper?

> The
> problem is, that git provides the version information of Buildroot.

 Is it that much of a problem if the Buildroot version is used?

> 
> To fix this, we patch the logic to retrieve the git version so it does
> not run git for mfgtools. Unfortunately, this breaks the build process
> because of the missing `gitversion.h` header file. Therefore, we add a
> post configure hook which generates this file with the correct version
> string.
> 
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> ---
>  .../0001-Fix-version-generation.patch         | 38 +++++++++++++++++++
>  package/mfgtools/mfgtools.hash                |  5 +--
>  package/mfgtools/mfgtools.mk                  | 35 ++++++-----------
>  3 files changed, 51 insertions(+), 27 deletions(-)
>  create mode 100644 package/mfgtools/0001-Fix-version-generation.patch
> 
> diff --git a/package/mfgtools/0001-Fix-version-generation.patch b/package/mfgtools/0001-Fix-version-generation.patch
> new file mode 100644
> index 0000000000..ca48c522ab
> --- /dev/null
> +++ b/package/mfgtools/0001-Fix-version-generation.patch
> @@ -0,0 +1,38 @@
> +From af9704ca3b7b02503f8ade069a77203869f0bcfa Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?J=C3=B6rg=20Krause?= <joerg.krause@embedded.rocks>
> +Date: Tue, 30 Apr 2019 15:51:47 +0200
> +Subject: [PATCH] Fix version generation
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +mfgtools uses git to extract its own version number.
> +
> +This is an issue as the git-extracted version is conflicting when a top
> +level project, e.g. a package manager, itself is a git repository.
> +
> +Since these git calls are legitimate only if git is used for the mfgtools
> +subtree only, this patch adds a check: A .git directory has to exist at
> +the root of the project to enable git-extracted version string.
> +
> +Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> +---
> + libuuu/gen_ver.sh | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/libuuu/gen_ver.sh b/libuuu/gen_ver.sh
> +index d4e8c1b..bcc04a2 100755
> +--- a/libuuu/gen_ver.sh
> ++++ b/libuuu/gen_ver.sh
> +@@ -13,7 +13,7 @@ else
> + fi
> + 
> + # Test if we are in a repo
> +-if [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ];
> ++if [ -d .git ] && [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ];

 The libuuu directory doesn't have a .git subdir. Also in some situations (e.g.
worktrees) .git may be a file or symlink.

> + then
> + 	#echo "In a repo"
> + 	# Get the version of the last commit of the repo
> +-- 
> +2.21.0
> +
> diff --git a/package/mfgtools/mfgtools.hash b/package/mfgtools/mfgtools.hash
> index 4932a80dba..4db97e6ae2 100644
> --- a/package/mfgtools/mfgtools.hash
> +++ b/package/mfgtools/mfgtools.hash
> @@ -1,4 +1,3 @@
>  # locally computed
> -sha256  055d71227d18883d6e8bc9e854c076015f9a7749820a94272e19071bf0b25c89  mfgtools-v0.02.tar.gz
> -sha256  2655559a6bb1179eae514f5c7166f4ede4f2453efa9cf4dc3c045cab5d57dede  LICENSE
> -sha256  0963b6e5086bf454265b0f57821a02b681d1211e40ad74c310231cb4d94815c9  README.txt
> +sha256  378caa930fdc1b06d49abf26811827f12103d995438b91302a7c6e34368419f9  mfgtools-uuu_1.2.91.tar.gz
> +sha256  cc8d47f7b9260f6669ecd41c24554c552f17581d81ee8fc602c6d23edb8bf495  LICENSE
> diff --git a/package/mfgtools/mfgtools.mk b/package/mfgtools/mfgtools.mk
> index e4663a8af9..c42b18d43b 100644
> --- a/package/mfgtools/mfgtools.mk
> +++ b/package/mfgtools/mfgtools.mk
> @@ -4,31 +4,18 @@
>  #
>  ################################################################################
>  
> -MFGTOOLS_VERSION = v0.02
> -MFGTOOLS_SITE = $(call github,codeauroraforum,mfgtools,$(MFGTOOLS_VERSION))
> -MFGTOOLS_SUBDIR = MfgToolLib
> -MFGTOOLS_LICENSE = BSD-3-Clause or CPOL
> -MFGTOOLS_LICENSE_FILES = LICENSE README.txt
> -HOST_MFGTOOLS_DEPENDENCIES = host-libusb
> +MFGTOOLS_VERSION = uuu_1.2.91
> +MFGTOOLS_SITE = $(call github,NXPmicro,mfgtools,$(MFGTOOLS_VERSION))
> +MFGTOOLS_LICENSE = BSD-3-Clause
> +MFGTOOLS_LICENSE_FILES = LICENSE
> +HOST_MFGTOOLS_DEPENDENCIES = host-libusb host-libzip host-zlib
>  
> -HOST_MFGTOOLS_CFLAGS = \
> -	$(HOST_CFLAGS) $(HOST_LDFLAGS) -std=c++11 -lpthread \
> -	-L$(@D)/MfgToolLib -lMfgToolLib -I$(@D)/MfgToolLib \
> -	-lusb-1.0 -I$(HOST_DIR)/include/libusb-1.0 \
> -	-fpermissive -Wno-write-strings
> -
> -define HOST_MFGTOOLS_CLI_BUILD
> -	$(HOST_CONFIGURE_OPTS) $(MAKE) CC="$(HOSTCXX)" \
> -		CFLAGS="$(HOST_MFGTOOLS_CFLAGS)" -C $(@D)/TestPrgm
> -endef
> -
> -HOST_MFGTOOLS_POST_BUILD_HOOKS += HOST_MFGTOOLS_CLI_BUILD
> -
> -define HOST_MFGTOOLS_INSTALL_CMDS
> -	$(INSTALL) -D -m 755 $(@D)/MfgToolLib/libMfgToolLib.so \
> -		$(HOST_DIR)/lib/libMfgToolLib.so
> -	$(INSTALL) -D -m 755 $(@D)/TestPrgm/mfgtoolcli \
> -		$(HOST_DIR)/bin/mfgtoolcli
> +# Version string generation is broken in mfgtools as it relies on git, even
> +# when building from a source tarball. We patch gen_ver.sh to prevent defining
> +# the GIT_VERSION in the build step and define GIT_VERSION ourself.
> +define MFGTOOLS_SET_VERSION
> +	echo '#define GIT_VERSION "lib$(MFGTOOLS_VERSION)"' > $(@D)/libuuu/gitversion.h

 Isn't this sufficient to avoid (re)generation of gitversion.h?

 Ah, no, it is a PRE_BUILD command so it is always run.

 Since the patch is anyway not upstreamable, maybe it's easier to do something
like this:

# Version string generation is broken in mfgtools as it relies on git, even
# when building from a source tarball. We overwrite gen_ver.sh with something
# that simply prints the version.
define MFGTOOLS_GEN_VER_SH
	echo '#! /bin/sh' > $(@D)/libuu/gen_ver.sh
	echo 'printf "$(MFGTOOLS_VERSION)" > $$1'  >> $(@D)/libuu/gen_ver.sh
	chmod +x  $(@D)/libuu/gen_ver.sh
endef
MFGTOOLS_POST_PATCH_HOOKS += MFGTOOLS_GEN_VER_SH


 Regards,
 Arnout

>  endef
> +HOST_MFGTOOLS_POST_CONFIGURE_HOOKS += MFGTOOLS_SET_VERSION
>  
>  $(eval $(host-cmake-package))
> 

[Buildroot] [PATCH 1/2] package/libzip: add host variant

[Arnout Vandecappelle]

On 30/04/2019 22:11, J?rg Krause wrote:
> The updated host mfgtool package needs the host variant of libzip.
> 
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>

 Applied to master, thanks.

 I marked them mfgtools bump itself as changes requested, so if you choose to
ignore my comments (or it doesn't work), please resubmit that one.

 Regards,
 Arnout

> ---
>  package/libzip/libzip.mk | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/package/libzip/libzip.mk b/package/libzip/libzip.mk
> index b90ea76f5e..280ca6d8c7 100644
> --- a/package/libzip/libzip.mk
> +++ b/package/libzip/libzip.mk
> @@ -11,6 +11,7 @@ LIBZIP_LICENSE = BSD-3-Clause
>  LIBZIP_LICENSE_FILES = LICENSE
>  LIBZIP_INSTALL_STAGING = YES
>  LIBZIP_DEPENDENCIES = zlib
> +HOST_LIBZIP_DEPENDENCIES = host-zlib
>  
>  ifeq ($(BR2_PACKAGE_BZIP2),y)
>  LIBZIP_DEPENDENCIES += bzip2
> @@ -33,3 +34,4 @@ LIBZIP_CONF_OPTS += -DENABLE_OPENSSL=OFF
>  endif
>  
>  $(eval $(cmake-package))
> +$(eval $(host-cmake-package))
> 

[Buildroot] [PATCH 2/2] package/mfgtools: bump to version 1.2.91

[Jörg Krause]

Hi Arnout,

On Wed, 2019-05-01 at 14:10 +0200, Arnout Vandecappelle wrote:
> 
> On 30/04/2019 22:11, J?rg Krause wrote:
> > The version 0.02 was a pre-release and is dated from Nov 20, 2017.
> > 
> > Meanwhile:
> >  * the repo owner switch to NXPmicro
> >  * latest version is 1.12.91
> >  * the build system is CMake
> >  * the license is BSD-3 only
> > 
> > Note, that mfgtools uses git to define a version string `GIT_VERSION`.
> > It does so even when building from the provided source tarball.
> 
>  Is there an upstream-provided tarball? If so, why do you use the github helper?

Unfortunately, no.

> > The
> > problem is, that git provides the version information of Buildroot.
> 
>  Is it that much of a problem if the Buildroot version is used?

mfgtools saves the version string in generated runtime scripts. So this
is a problem.

> > To fix this, we patch the logic to retrieve the git version so it does
> > not run git for mfgtools. Unfortunately, this breaks the build process
> > because of the missing `gitversion.h` header file. Therefore, we add a
> > post configure hook which generates this file with the correct version
> > string.
> > 
> > Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> > ---
> >  .../0001-Fix-version-generation.patch         | 38 +++++++++++++++++++
> >  package/mfgtools/mfgtools.hash                |  5 +--
> >  package/mfgtools/mfgtools.mk                  | 35 ++++++-----------
> >  3 files changed, 51 insertions(+), 27 deletions(-)
> >  create mode 100644 package/mfgtools/0001-Fix-version-generation.patch
> > 
> > diff --git a/package/mfgtools/0001-Fix-version-generation.patch b/package/mfgtools/0001-Fix-version-generation.patch
> > new file mode 100644
> > index 0000000000..ca48c522ab
> > --- /dev/null
> > +++ b/package/mfgtools/0001-Fix-version-generation.patch
> > @@ -0,0 +1,38 @@
> > +From af9704ca3b7b02503f8ade069a77203869f0bcfa Mon Sep 17 00:00:00 2001
> > +From: =?UTF-8?q?J=C3=B6rg=20Krause?= <joerg.krause@embedded.rocks>
> > +Date: Tue, 30 Apr 2019 15:51:47 +0200
> > +Subject: [PATCH] Fix version generation
> > +MIME-Version: 1.0
> > +Content-Type: text/plain; charset=UTF-8
> > +Content-Transfer-Encoding: 8bit
> > +
> > +mfgtools uses git to extract its own version number.
> > +
> > +This is an issue as the git-extracted version is conflicting when a top
> > +level project, e.g. a package manager, itself is a git repository.
> > +
> > +Since these git calls are legitimate only if git is used for the mfgtools
> > +subtree only, this patch adds a check: A .git directory has to exist at
> > +the root of the project to enable git-extracted version string.
> > +
> > +Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> > +---
> > + libuuu/gen_ver.sh | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/libuuu/gen_ver.sh b/libuuu/gen_ver.sh
> > +index d4e8c1b..bcc04a2 100755
> > +--- a/libuuu/gen_ver.sh
> > ++++ b/libuuu/gen_ver.sh
> > +@@ -13,7 +13,7 @@ else
> > + fi
> > + 
> > + # Test if we are in a repo
> > +-if [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ];
> > ++if [ -d .git ] && [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ];
> 
>  The libuuu directory doesn't have a .git subdir. Also in some situations (e.g.
> worktrees) .git may be a file or symlink.
> 
> > + then
> > + 	#echo "In a repo"
> > + 	# Get the version of the last commit of the repo
> > +-- 
> > +2.21.0
> > +
> > diff --git a/package/mfgtools/mfgtools.hash b/package/mfgtools/mfgtools.hash
> > index 4932a80dba..4db97e6ae2 100644
> > --- a/package/mfgtools/mfgtools.hash
> > +++ b/package/mfgtools/mfgtools.hash
> > @@ -1,4 +1,3 @@
> >  # locally computed
> > -sha256  055d71227d18883d6e8bc9e854c076015f9a7749820a94272e19071bf0b25c89  mfgtools-v0.02.tar.gz
> > -sha256  2655559a6bb1179eae514f5c7166f4ede4f2453efa9cf4dc3c045cab5d57dede  LICENSE
> > -sha256  0963b6e5086bf454265b0f57821a02b681d1211e40ad74c310231cb4d94815c9  README.txt
> > +sha256  378caa930fdc1b06d49abf26811827f12103d995438b91302a7c6e34368419f9  mfgtools-uuu_1.2.91.tar.gz
> > +sha256  cc8d47f7b9260f6669ecd41c24554c552f17581d81ee8fc602c6d23edb8bf495  LICENSE
> > diff --git a/package/mfgtools/mfgtools.mk b/package/mfgtools/mfgtools.mk
> > index e4663a8af9..c42b18d43b 100644
> > --- a/package/mfgtools/mfgtools.mk
> > +++ b/package/mfgtools/mfgtools.mk
> > @@ -4,31 +4,18 @@
> >  #
> >  ################################################################################
> >  
> > -MFGTOOLS_VERSION = v0.02
> > -MFGTOOLS_SITE = $(call github,codeauroraforum,mfgtools,$(MFGTOOLS_VERSION))
> > -MFGTOOLS_SUBDIR = MfgToolLib
> > -MFGTOOLS_LICENSE = BSD-3-Clause or CPOL
> > -MFGTOOLS_LICENSE_FILES = LICENSE README.txt
> > -HOST_MFGTOOLS_DEPENDENCIES = host-libusb
> > +MFGTOOLS_VERSION = uuu_1.2.91
> > +MFGTOOLS_SITE = $(call github,NXPmicro,mfgtools,$(MFGTOOLS_VERSION))
> > +MFGTOOLS_LICENSE = BSD-3-Clause
> > +MFGTOOLS_LICENSE_FILES = LICENSE
> > +HOST_MFGTOOLS_DEPENDENCIES = host-libusb host-libzip host-zlib
> >  
> > -HOST_MFGTOOLS_CFLAGS = \
> > -	$(HOST_CFLAGS) $(HOST_LDFLAGS) -std=c++11 -lpthread \
> > -	-L$(@D)/MfgToolLib -lMfgToolLib -I$(@D)/MfgToolLib \
> > -	-lusb-1.0 -I$(HOST_DIR)/include/libusb-1.0 \
> > -	-fpermissive -Wno-write-strings
> > -
> > -define HOST_MFGTOOLS_CLI_BUILD
> > -	$(HOST_CONFIGURE_OPTS) $(MAKE) CC="$(HOSTCXX)" \
> > -		CFLAGS="$(HOST_MFGTOOLS_CFLAGS)" -C $(@D)/TestPrgm
> > -endef
> > -
> > -HOST_MFGTOOLS_POST_BUILD_HOOKS += HOST_MFGTOOLS_CLI_BUILD
> > -
> > -define HOST_MFGTOOLS_INSTALL_CMDS
> > -	$(INSTALL) -D -m 755 $(@D)/MfgToolLib/libMfgToolLib.so \
> > -		$(HOST_DIR)/lib/libMfgToolLib.so
> > -	$(INSTALL) -D -m 755 $(@D)/TestPrgm/mfgtoolcli \
> > -		$(HOST_DIR)/bin/mfgtoolcli
> > +# Version string generation is broken in mfgtools as it relies on git, even
> > +# when building from a source tarball. We patch gen_ver.sh to prevent defining
> > +# the GIT_VERSION in the build step and define GIT_VERSION ourself.
> > +define MFGTOOLS_SET_VERSION
> > +	echo '#define GIT_VERSION "lib$(MFGTOOLS_VERSION)"' > $(@D)/libuuu/gitversion.h
> 
>  Isn't this sufficient to avoid (re)generation of gitversion.h?
> 
>  Ah, no, it is a PRE_BUILD command so it is always run.
> 
>  Since the patch is anyway not upstreamable, maybe it's easier to do something
> like this:
> 
> # Version string generation is broken in mfgtools as it relies on git, even
> # when building from a source tarball. We overwrite gen_ver.sh with something
> # that simply prints the version.
> define MFGTOOLS_GEN_VER_SH
> 	echo '#! /bin/sh' > $(@D)/libuu/gen_ver.sh
> 	echo 'printf "$(MFGTOOLS_VERSION)" > $$1'  >> $(@D)/libuu/gen_ver.sh
> 	chmod +x  $(@D)/libuu/gen_ver.sh
> endef
> MFGTOOLS_POST_PATCH_HOOKS += MFGTOOLS_GEN_VER_SH

Yes, this should work. I will prepare an updated patch.

Thanks!

Best regards
J?rg Krause

[Buildroot] [PATCH 2/2] package/mfgtools: bump to version 1.2.91

[Arnout Vandecappelle]

On 02/05/2019 08:51, J?rg Krause wrote:
>>> The
>>> problem is, that git provides the version information of Buildroot.
>>  Is it that much of a problem if the Buildroot version is used?
> mfgtools saves the version string in generated runtime scripts. So this
> is a problem.

 Yes, I understand that. But the effect is that `uuu --version` will print
2019.02 instead of 1.2.91, right? So my question is: is it that much of a
problem that this happens?

 I'm asking because I'm sure there are other packages that have that behaviour.
Are we going to try to find and fix all of them? Or just live with the fact that
some packages report the wrong version?

 Regards,
 Arnout

[Buildroot] [PATCH 2/2] package/mfgtools: bump to version 1.2.91

[yann.morin at orange.com]

Arnout, All,

On 2019-05-02 09:52 +0200, Arnout Vandecappelle spake thusly:
> On 02/05/2019 08:51, J?rg Krause wrote:
> >>> The
> >>> problem is, that git provides the version information of Buildroot.
> >>  Is it that much of a problem if the Buildroot version is used?
> > mfgtools saves the version string in generated runtime scripts. So this
> > is a problem.
> 
>  Yes, I understand that. But the effect is that `uuu --version` will print
> 2019.02 instead of 1.2.91, right? So my question is: is it that much of a
> problem that this happens?
> 
>  I'm asking because I'm sure there are other packages that have that behaviour.
> Are we going to try to find and fix all of them? Or just live with the fact that
> some packages report the wrong version?

I think the real issue is that, for out-of-tree builds, there might be
no git tree available, and thus those packages would FTBFS. This means
we would eventually cactch such packages.

Furthermore, it would be pretty surprising for unsuspecting users to end
up with Buildroot's version instead of that package's version.

As such, your proposal to replace the version script is good idea.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
| +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
|      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

[Buildroot] [PATCH 2/2] package/mfgtools: bump to version 1.2.91

[Jörg Krause]

On Thu, 2019-05-02 at 09:52 +0200, Arnout Vandecappelle wrote:
> 
> On 02/05/2019 08:51, J?rg Krause wrote:
> > > > The
> > > > problem is, that git provides the version information of Buildroot.
> > >  Is it that much of a problem if the Buildroot version is used?
> > mfgtools saves the version string in generated runtime scripts. So this
> > is a problem.
> 
>  Yes, I understand that. But the effect is that `uuu --version` will print
> 2019.02 instead of 1.2.91, right? So my question is: is it that much of a
> problem that this happens?

mfgtools checks its version information with a version string saved in
user provided command list files. If the version string of the file is
newer than the version of mfgtools it will abort. So, yes, it is a
problem.

>  I'm asking because I'm sure there are other packages that have that behaviour.
> Are we going to try to find and fix all of them? Or just live with the fact that
> some packages report the wrong version?

There are! The issue with such packages is when filing a bug report for
upstream, the maintainer might wonder about the strange version
information.

Best regards
J?rg Krause

[Buildroot] [PATCH 2/2] package/mfgtools: bump to version 1.2.91

[Jörg Krause]

On Thu, 2019-05-02 at 10:01 +0200, yann.morin at orange.com wrote:
> Arnout, All,
> 
> On 2019-05-02 09:52 +0200, Arnout Vandecappelle spake thusly:
> > On 02/05/2019 08:51, J?rg Krause wrote:
> > > > > The
> > > > > problem is, that git provides the version information of Buildroot.
> > > >  Is it that much of a problem if the Buildroot version is used?
> > > mfgtools saves the version string in generated runtime scripts. So this
> > > is a problem.
> > 
> >  Yes, I understand that. But the effect is that `uuu --version` will print
> > 2019.02 instead of 1.2.91, right? So my question is: is it that much of a
> > problem that this happens?
> > 
> >  I'm asking because I'm sure there are other packages that have that behaviour.
> > Are we going to try to find and fix all of them? Or just live with the fact that
> > some packages report the wrong version?
> 
> I think the real issue is that, for out-of-tree builds, there might be
> no git tree available, and thus those packages would FTBFS. This means
> we would eventually cactch such packages.

That's correct for mfgtools for example. When building with Buildroot
extracted from the tarball it will not compile as it misses
gitversion.h. This issue has been reported upstream.

> Furthermore, it would be pretty surprising for unsuspecting users to end
> up with Buildroot's version instead of that package's version.
> 
> As such, your proposal to replace the version script is good idea.

I agree!

Best regards
J?rg Krause