diff mbox

[4/5] gtest: Upgrade to GitHub HEAD

Message ID 1444859483-2268-5-git-send-email-alan@softiron.co.uk
State Changes Requested
Headers show

Commit Message

Alan Ott Oct. 14, 2015, 9:51 p.m. UTC
Google Code is being shut down. The google code site which hosts the
source .zip for gtest references github.com/google/googletest, but that
repo does not have the same code underneath the versioned tags as the
google code repo.  For this reason It was decided by Peter Korsgaard and I
to upgrade to the current HEAD. The current HEAD is laid out
differently (with gtest and gmock combined into the same repo).

Change the GTEST_SITE to this new github repo, fix the version, fix the
paths, and remove the custom extraction commands.

Signed-off-by: Alan Ott <alan@softiron.co.uk>
---
 package/gtest/gtest.hash |  4 ++--
 package/gtest/gtest.mk   | 19 ++++++++-----------
 2 files changed, 10 insertions(+), 13 deletions(-)

Comments

Thomas Petazzoni Oct. 14, 2015, 9:55 p.m. UTC | #1
Alan,

On Wed, 14 Oct 2015 17:51:22 -0400, Alan Ott wrote:

> +# The above revision must remain the same as the gmock package
> +GTEST_SITE = $(call github,google,googletest,$(GTEST_VERSION))
>  GTEST_INSTALL_STAGING = YES
>  GTEST_INSTALL_TARGET = NO
>  GTEST_LICENSE = BSD-3c
>  GTEST_LICENSE_FILES = LICENSE
> +GTEST_SUBDIR = googletest

So gtest and gmock are in fact now part of the same repository/upstream
project ? If that's the case, then I think we should simply get rid of
the gtest and gmock packages, and have a single package named
"googletest".

Thomas
Alan Ott Oct. 14, 2015, 10 p.m. UTC | #2
On 10/14/2015 05:55 PM, Thomas Petazzoni wrote:
> On Wed, 14 Oct 2015 17:51:22 -0400, Alan Ott wrote:
>
>> +# The above revision must remain the same as the gmock package
>> +GTEST_SITE = $(call github,google,googletest,$(GTEST_VERSION))
>>   GTEST_INSTALL_STAGING = YES
>>   GTEST_INSTALL_TARGET = NO
>>   GTEST_LICENSE = BSD-3c
>>   GTEST_LICENSE_FILES = LICENSE
>> +GTEST_SUBDIR = googletest
> So gtest and gmock are in fact now part of the same repository/upstream
> project ? If that's the case, then I think we should simply get rid of
> the gtest and gmock packages, and have a single package named
> "googletest".

Yes, that would probably be better. gmock depends on gtest, and gtest 
can be standalone. Maybe we have one package with a submenu option to 
build each target (and a dependency so gmock selects gtest).

Is that ok by you?

Alan.
Thomas Petazzoni Oct. 15, 2015, 7:10 a.m. UTC | #3
Dear Alan Ott,

On Wed, 14 Oct 2015 18:00:44 -0400, Alan Ott wrote:

> > So gtest and gmock are in fact now part of the same repository/upstream
> > project ? If that's the case, then I think we should simply get rid of
> > the gtest and gmock packages, and have a single package named
> > "googletest".
> 
> Yes, that would probably be better. gmock depends on gtest, and gtest 
> can be standalone. Maybe we have one package with a submenu option to 
> build each target (and a dependency so gmock selects gtest).
> 
> Is that ok by you?

Yes, that's OK.

Thomas
Carlos Santos Oct. 19, 2015, 7:29 p.m. UTC | #4
Hello, Thomas and Alan,

> From: "Alan Ott" <alan@softiron.co.uk>
> To: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> Cc: buildroot@buildroot.org
> Sent: Wednesday, October 14, 2015 7:00:44 PM
> Subject: Re: [Buildroot] [PATCH 4/5] gtest: Upgrade to GitHub HEAD

> On 10/14/2015 05:55 PM, Thomas Petazzoni wrote:
>> On Wed, 14 Oct 2015 17:51:22 -0400, Alan Ott wrote:
>>
>>> +# The above revision must remain the same as the gmock package
>>> +GTEST_SITE = $(call github,google,googletest,$(GTEST_VERSION))
>>>   GTEST_INSTALL_STAGING = YES
>>>   GTEST_INSTALL_TARGET = NO
>>>   GTEST_LICENSE = BSD-3c
>>>   GTEST_LICENSE_FILES = LICENSE
>>> +GTEST_SUBDIR = googletest
>> So gtest and gmock are in fact now part of the same repository/upstream
>> project ? If that's the case, then I think we should simply get rid of
>> the gtest and gmock packages, and have a single package named
>> "googletest".

What about applying the submitted patches now, to fix the repository, and a different patch later to create the "googletest" package?

> Yes, that would probably be better. gmock depends on gtest, and gtest
> can be standalone. Maybe we have one package with a submenu option to
> build each target (and a dependency so gmock selects gtest).
> 
> Is that ok by you?
> 
> Alan.

Do you need any help to do this?

Carlos Santos (Casantos)
DATACOM, P&D
Carlos Santos Feb. 17, 2016, 6:17 p.m. UTC | #5
> From: "Carlos Santos" <casantos@datacom.ind.br>
> To: "Alan Ott" <alan@softiron.co.uk>
> Cc: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>, buildroot@buildroot.org
> Sent: Monday, October 19, 2015 5:29:26 PM
> Subject: Re: [Buildroot] [PATCH 4/5] gtest: Upgrade to GitHub HEAD

> Hello, Thomas and Alan,
> 
>> From: "Alan Ott" <alan@softiron.co.uk>
>> To: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
>> Cc: buildroot@buildroot.org
>> Sent: Wednesday, October 14, 2015 7:00:44 PM
>> Subject: Re: [Buildroot] [PATCH 4/5] gtest: Upgrade to GitHub HEAD
> 
>> On 10/14/2015 05:55 PM, Thomas Petazzoni wrote:
>>> On Wed, 14 Oct 2015 17:51:22 -0400, Alan Ott wrote:
>>>
>>>> +# The above revision must remain the same as the gmock package
>>>> +GTEST_SITE = $(call github,google,googletest,$(GTEST_VERSION))
>>>>   GTEST_INSTALL_STAGING = YES
>>>>   GTEST_INSTALL_TARGET = NO
>>>>   GTEST_LICENSE = BSD-3c
>>>>   GTEST_LICENSE_FILES = LICENSE
>>>> +GTEST_SUBDIR = googletest
>>> So gtest and gmock are in fact now part of the same repository/upstream
>>> project ? If that's the case, then I think we should simply get rid of
>>> the gtest and gmock packages, and have a single package named
>>> "googletest".
> 
> What about applying the submitted patches now, to fix the repository, and a
> different patch later to create the "googletest" package?
> 
>> Yes, that would probably be better. gmock depends on gtest, and gtest
>> can be standalone. Maybe we have one package with a submenu option to
>> build each target (and a dependency so gmock selects gtest).
>> 
>> Is that ok by you?
>> 
>> Alan.
> 
> Do you need any help to do this?

Hello Alan,

I noticed that this patch set is still in "Changes Requested" state. Is there anything I can do to help?

Carlos Santos (Casantos)
DATACOM, P&D
Thomas Petazzoni Feb. 17, 2016, 8:50 p.m. UTC | #6
Hello,

On Wed, 17 Feb 2016 16:17:12 -0200 (BRST), Carlos Santos wrote:

> Hello Alan,
> 
> I noticed that this patch set is still in "Changes Requested" state. Is there anything I can do to help?

You can take over the patch, make the necessary changes and post an
updated version of it.

If your changes are limited, it is customary to keep the original
author as the author of the patch.

If your changes are really major and essentially rewrite the whole
patch, then you can re-assign the authorship of the patch to you, but
keep a reference to the original author in the commit log.

It is definitely more than welcome to pick up old patches for which
changes were requested, but whose author didn't had the time to
implement.

Best regards,

Thomas
Alan Ott Feb. 18, 2016, 12:13 a.m. UTC | #7
On February 17, 2016 1:50:23 PM MST, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>Hello,
>
>On Wed, 17 Feb 2016 16:17:12 -0200 (BRST), Carlos Santos wrote:
>
>> Hello Alan,
>> 
>> I noticed that this patch set is still in "Changes Requested" state.
>Is there anything I can do to help?
>
>You can take over the patch, make the necessary changes and post an
>updated version of it.
>
>If your changes are limited, it is customary to keep the original
>author as the author of the patch.
>
>If your changes are really major and essentially rewrite the whole
>patch, then you can re-assign the authorship of the patch to you, but
>keep a reference to the original author in the commit log.
>
>It is definitely more than welcome to pick up old patches for which
>changes were requested, but whose author didn't had the time to
>implement.
>

Hi Carlos, I agree. I ran out of time on this, unfortunately :( .Have a look at the original comments from Thomas here:
https://patchwork.ozlabs.org/patch/530390/

As far as a authorship, the changes requested are significant enough that you can take my authorship off. I don't mind.

Alan.
Carlos Santos Feb. 18, 2016, 4:14 p.m. UTC | #8
> From: "Alan Ott" <alan@softiron.co.uk>
> To: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>, "Carlos Santos" <casantos@datacom.ind.br>
> Cc: buildroot@buildroot.org
> Sent: Wednesday, February 17, 2016 10:13:39 PM
> Subject: Re: [Buildroot] [PATCH 4/5] gtest: Upgrade to GitHub HEAD

> On February 17, 2016 1:50:23 PM MST, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>Hello,
>>
>>On Wed, 17 Feb 2016 16:17:12 -0200 (BRST), Carlos Santos wrote:
>>
>>> Hello Alan,
>>> 
>>> I noticed that this patch set is still in "Changes Requested" state.
>>Is there anything I can do to help?
>>
>>You can take over the patch, make the necessary changes and post an
>>updated version of it.
>>
>>If your changes are limited, it is customary to keep the original
>>author as the author of the patch.
>>
>>If your changes are really major and essentially rewrite the whole
>>patch, then you can re-assign the authorship of the patch to you, but
>>keep a reference to the original author in the commit log.
>>
>>It is definitely more than welcome to pick up old patches for which
>>changes were requested, but whose author didn't had the time to
>>implement.
>>
> 
> Hi Carlos, I agree. I ran out of time on this, unfortunately :( .Have a look at
> the original comments from Thomas here:
> https://patchwork.ozlabs.org/patch/530390/
> 
> As far as a authorship, the changes requested are significant enough that you
> can take my authorship off. I don't mind.
> 
> Alan.

Alan/Thomas,

I propose doing this in three steps:

1. Submit a patchset that replaces the sites from googlecode.com to github, maintaining the same package versions (including gtest and gmock, that would be left at version 1.7.0).

This change is easy to apply and could even be brought to the impending Buildroot 2016.02, IMO, since it does not change the package versions, only reduces the risk of build failures due to problems in googlecode.com (I consider this a bug fix). The patchset would update the following patches:

    http://patchwork.ozlabs.org/patch/530387/
    http://patchwork.ozlabs.org/patch/530388/
    http://patchwork.ozlabs.org/patch/530389/
    http://patchwork.ozlabs.org/patch/530390/
    http://patchwork.ozlabs.org/patch/530391/


2. Submit a patchset that replaces packages gtest and gmock by a "googletest" package, as suggested by Thomas. This change is quite disruptive for us at DATACOM because it may require changing the recipes that we maintain in $(BR2_EXTERNAL), so I humbly ask you to postpone the change.

3. Submit a patchset that upgrades googletest to a newer release, hopefully v1.8.0, or to the current HEAD, as decided by Peter Korsgaard and Alan. I will do this after ensuring that the change does not break anything.

Do you agree?

Carlos Santos (Casantos)
DATACOM, P&D
Thomas Petazzoni Feb. 18, 2016, 4:18 p.m. UTC | #9
Hello,

On Thu, 18 Feb 2016 14:14:26 -0200 (BRST), Carlos Santos wrote:

> 1. Submit a patchset that replaces the sites from googlecode.com to github, maintaining the same package versions (including gtest and gmock, that would be left at version 1.7.0).
> 
> This change is easy to apply and could even be brought to the impending Buildroot 2016.02, IMO, since it does not change the package versions, only reduces the risk of build failures due to problems in googlecode.com (I consider this a bug fix). The patchset would update the following patches:
> 
>     http://patchwork.ozlabs.org/patch/530387/
>     http://patchwork.ozlabs.org/patch/530388/
>     http://patchwork.ozlabs.org/patch/530389/
>     http://patchwork.ozlabs.org/patch/530390/
>     http://patchwork.ozlabs.org/patch/530391/
> 
> 
> 2. Submit a patchset that replaces packages gtest and gmock by a "googletest" package, as suggested by Thomas. This change is quite disruptive for us at DATACOM because it may require changing the recipes that we maintain in $(BR2_EXTERNAL), so I humbly ask you to postpone the change.
> 
> 3. Submit a patchset that upgrades googletest to a newer release, hopefully v1.8.0, or to the current HEAD, as decided by Peter Korsgaard and Alan. I will do this after ensuring that the change does not break anything.

Sounds good. Note that (1), (2) and (3) could also be part of the same
patch series if you wish. But it's fine to have (1) first, wait to get
it merge, and only then continue with (2) and (3).

Best regards,

Thomas
Carlos Santos Feb. 18, 2016, 7:26 p.m. UTC | #10
> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: "Alan Ott" <alan@softiron.co.uk>, buildroot@buildroot.org
> Sent: Thursday, February 18, 2016 2:18:14 PM
> Subject: Re: [Buildroot] [PATCH 4/5] gtest: Upgrade to GitHub HEAD

> Hello,
> 
> On Thu, 18 Feb 2016 14:14:26 -0200 (BRST), Carlos Santos wrote:
> 
>> 1. Submit a patchset that replaces the sites from googlecode.com to github,
>> maintaining the same package versions (including gtest and gmock, that would be
>> left at version 1.7.0).
>> 
>> This change is easy to apply and could even be brought to the impending
>> Buildroot 2016.02, IMO, since it does not change the package versions, only
>> reduces the risk of build failures due to problems in googlecode.com (I
>> consider this a bug fix). The patchset would update the following patches:
>> 
>>     http://patchwork.ozlabs.org/patch/530387/
>>     http://patchwork.ozlabs.org/patch/530388/
>>     http://patchwork.ozlabs.org/patch/530389/
>>     http://patchwork.ozlabs.org/patch/530390/
>>     http://patchwork.ozlabs.org/patch/530391/
>> 
>> 
>> 2. Submit a patchset that replaces packages gtest and gmock by a "googletest"
>> package, as suggested by Thomas. This change is quite disruptive for us at
>> DATACOM because it may require changing the recipes that we maintain in
>> $(BR2_EXTERNAL), so I humbly ask you to postpone the change.
>> 
>> 3. Submit a patchset that upgrades googletest to a newer release, hopefully
>> v1.8.0, or to the current HEAD, as decided by Peter Korsgaard and Alan. I will
>> do this after ensuring that the change does not break anything.
> 
> Sounds good. Note that (1), (2) and (3) could also be part of the same
> patch series if you wish. But it's fine to have (1) first, wait to get
> it merge, and only then continue with (2) and (3).

Thomas,

Considering that my work will focus on GTest/GMock I thing that patches 530387 through 530389 can be applied, leaving 530390 and 530391 in "Changes Requested" state. Do you agree?

Carlos Santos (Casantos)
DATACOM, P&D
diff mbox

Patch

diff --git a/package/gtest/gtest.hash b/package/gtest/gtest.hash
index 8ff79cb..af6a25a 100644
--- a/package/gtest/gtest.hash
+++ b/package/gtest/gtest.hash
@@ -1,2 +1,2 @@ 
-# From http://code.google.com/p/googletest/downloads/detail?name=gtest-1.7.0.zip&can=2&q=
-sha1	f85f6d2481e2c6c4a18539e391aa4ea8ab0394af	gtest-1.7.0.zip
+# Locally computed:
+sha256	58d1b6118176b527301c03010b7cb709b7c4b729078a55e4bb3341dfb40f5834	gtest-7f4448f40b3f3f16a75787c016139511579367ed.tar.gz
diff --git a/package/gtest/gtest.mk b/package/gtest/gtest.mk
index da08621..6894f73 100644
--- a/package/gtest/gtest.mk
+++ b/package/gtest/gtest.mk
@@ -5,13 +5,14 @@ 
 ################################################################################
 
 # Make sure this remains the same version as the gmock one
-GTEST_VERSION = 1.7.0
-GTEST_SOURCE = gtest-$(GTEST_VERSION).zip
-GTEST_SITE = http://googletest.googlecode.com/files
+GTEST_VERSION = 7f4448f40b3f3f16a75787c016139511579367ed
+# The above revision must remain the same as the gmock package
+GTEST_SITE = $(call github,google,googletest,$(GTEST_VERSION))
 GTEST_INSTALL_STAGING = YES
 GTEST_INSTALL_TARGET = NO
 GTEST_LICENSE = BSD-3c
 GTEST_LICENSE_FILES = LICENSE
+GTEST_SUBDIR = googletest
 
 # While it is possible to build gtest as shared library, using this gtest shared
 # library requires to set some special configure option in the project using
@@ -22,15 +23,11 @@  GTEST_LICENSE_FILES = LICENSE
 # the gtest sources.
 GTEST_CONF_OPTS = -DBUILD_SHARED_LIBS=OFF
 
-define GTEST_EXTRACT_CMDS
-	$(UNZIP) $(DL_DIR)/$(GTEST_SOURCE) -d $(BUILD_DIR)
-endef
-
 define GTEST_INSTALL_STAGING_CMDS
-	$(INSTALL) -D -m 0755 $(@D)/libgtest.a $(STAGING_DIR)/usr/lib/libgtest.a
-	$(INSTALL) -D -m 0755 $(@D)/libgtest_main.a $(STAGING_DIR)/usr/lib/libgtest_main.a
+	$(INSTALL) -D -m 0755 $(@D)/$(GTEST_SUBDIR)/libgtest.a $(STAGING_DIR)/usr/lib/libgtest.a
+	$(INSTALL) -D -m 0755 $(@D)/$(GTEST_SUBDIR)/libgtest_main.a $(STAGING_DIR)/usr/lib/libgtest_main.a
 	$(INSTALL) -d -m 0755 $(STAGING_DIR)/usr/include/gtest/
-	cp -rp $(@D)/include/gtest/* $(STAGING_DIR)/usr/include/gtest/
+	cp -rp $(@D)/$(GTEST_SUBDIR)/include/gtest/* $(STAGING_DIR)/usr/include/gtest/
 	# Generate the gtest-config script manually, since the CMake
 	# build system is not doing it.
 	sed 's%@PACKAGE_TARNAME@%gtest%;\
@@ -42,7 +39,7 @@  define GTEST_INSTALL_STAGING_CMDS
 		s%@bindir@%$(STAGING_DIR)/usr/bin%;\
 		s%@PTHREAD_CFLAGS@%%;\
 		s%@PTHREAD_LIBS@%-lpthread%;' \
-		$(@D)/scripts/gtest-config.in \
+		$(@D)/$(GTEST_SUBDIR)/scripts/gtest-config.in \
 		> $(STAGING_DIR)/usr/bin/gtest-config
 	chmod +x $(STAGING_DIR)/usr/bin/gtest-config
 endef