[v2] poco: build it as "poco", not "poco-poco"

Use just the version number to name the tarball and build directory, not
the full tag "poco-x.y.z-release". I admit that this is pure nitpicking
but, gosh, that "poco-poco" thing puts me nervous!

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
---
Changes v1->v2
 - Embed POCO_VERSION in POCO_VERSION_TAg, as suggested by Bernd Kuhls

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
---
 package/poco/poco.hash | 2 +-
 package/poco/poco.mk   | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

Hello,

On Sat, 11 Feb 2017 09:15:55 -0200, Carlos Santos wrote:

> -POCO_VERSION = poco-1.7.2-release
> -POCO_SITE = $(call github,pocoproject,poco,$(POCO_VERSION))
> +POCO_VERSION = 1.7.2
> +POCO_VERSION_TAG = poco-$(POCO_VERSION)-release
> +POCO_SITE = $(call github,pocoproject,poco,$(POCO_VERSION_TAG))

In all packages, we currently use directly the upstream tag name as the
<pkg>_VERSION value. I.e, we already had some people who wanted to do:

FOO_VERSION = 1.2.3
FOO_SITE = $(call github,foo,bar,v$(FOO_VERSION))

and we said no, the version should be v1.2.3.

So I'm not sure why we would want to do this differently for the poco
package. Yes, poco-poco-1.7.2-release seems weird, but if you find this
weird, then it's upstream who should change the name of their tags.

That being said, one thing that might lead us to change our mind is
when we will do tracking of new upstream releases. In this situation,
it might be easier to have a "cleaner" <pkg>_VERSION variable. See for
example the list of versions visible at
https://release-monitoring.org/project/5418/.

Thomas

> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: buildroot@buildroot.org, "bernd kuhls" <bernd.kuhls@t-online.de>, "Yann E. MORIN" <yann.morin.1998@free.fr>, "Peter
> Korsgaard" <peter@korsgaard.com>
> Sent: Saturday, February 11, 2017 1:48:37 PM
> Subject: Re: [Buildroot] [PATCH v2] poco: build it as "poco", not "poco-poco"

> Hello,
> 
> On Sat, 11 Feb 2017 09:15:55 -0200, Carlos Santos wrote:
> 
>> -POCO_VERSION = poco-1.7.2-release
>> -POCO_SITE = $(call github,pocoproject,poco,$(POCO_VERSION))
>> +POCO_VERSION = 1.7.2
>> +POCO_VERSION_TAG = poco-$(POCO_VERSION)-release
>> +POCO_SITE = $(call github,pocoproject,poco,$(POCO_VERSION_TAG))
> 
> In all packages, we currently use directly the upstream tag name as the
> <pkg>_VERSION value. I.e, we already had some people who wanted to do:
> 
> FOO_VERSION = 1.2.3
> FOO_SITE = $(call github,foo,bar,v$(FOO_VERSION))
> 
> and we said no, the version should be v1.2.3.
> 
> So I'm not sure why we would want to do this differently for the poco
> package. Yes, poco-poco-1.7.2-release seems weird, but if you find this
> weird, then it's upstream who should change the name of their tags.

They would probably interpret such request as me asking them to
scratch my itches (just like you are probably feeling now, sorry).

> That being said, one thing that might lead us to change our mind is
> when we will do tracking of new upstream releases. In this situation,
> it might be easier to have a "cleaner" <pkg>_VERSION variable. See for
> example the list of versions visible at
> https://release-monitoring.org/project/5418/.

Right. That "poco" and "release" prefix/suffix in the tag are mere
embellishments. In fact I sent this change because when the poco
compilation stated to fail on our multicore autobuilders (see commit
126162b9159a185ac1897db1a9956f0379fc1428) people here asked me to fix
that "poco-poco" issue.

They really thought that the package name was "poco-poco", due to the
build log (see the last three lines in http://bit.ly/2lw46Dl) and
during my tests I even attempted a "make poco-poco-rebuild", which
obviously failed with a "No rule to make target 'poco-poco-rebuild'"
error. That's really annoying.

> Thomas

Carlos Santos (Casantos) - DATACOM, P&D
“Something must be done. This is something. Therefore we must do it.”
(from the BBC series “Yes, Prime Minister”, “Power to the people”)

Thomas, All,

On 2017-02-11 16:48 +0100, Thomas Petazzoni spake thusly:
> On Sat, 11 Feb 2017 09:15:55 -0200, Carlos Santos wrote:
> 
> > -POCO_VERSION = poco-1.7.2-release
> > -POCO_SITE = $(call github,pocoproject,poco,$(POCO_VERSION))
> > +POCO_VERSION = 1.7.2
> > +POCO_VERSION_TAG = poco-$(POCO_VERSION)-release
> > +POCO_SITE = $(call github,pocoproject,poco,$(POCO_VERSION_TAG))
> 
> In all packages, we currently use directly the upstream tag name as the
> <pkg>_VERSION value. I.e, we already had some people who wanted to do:
> 
> FOO_VERSION = 1.2.3
> FOO_SITE = $(call github,foo,bar,v$(FOO_VERSION))
> 
> and we said no, the version should be v1.2.3.

Actually, there are 13 packagers where this is the case:

    package/libcec/libcec.mk:LIBCEC_SITE = $(call github,Pulse-Eight,libcec,libcec-$(LIBCEC_VERSION))
    package/libiio/libiio.mk:LIBIIO_SITE = $(call github,analogdevicesinc,libiio,v$(LIBIIO_VERSION))
    package/libplatform/libplatform.mk:LIBPLATFORM_SITE = $(call github,Pulse-Eight,platform,p8-platform-$(LIBPLATFORM_VERSION))
    package/luaposix/luaposix.mk:LUAPOSIX_SITE = $(call github,luaposix,luaposix,release-v$(LUAPOSIX_VERSION))
    package/msr-tools/msr-tools.mk:MSR_TOOLS_SITE = $(call github,01org,msr-tools,msr-tools-$(MSR_TOOLS_VERSION))
    package/nodm/nodm.mk:NODM_SITE = $(call github,spanezz,nodm,debian/$(NODM_VERSION))
    package/openjpeg/openjpeg.mk:OPENJPEG_SITE = $(call github,uclouvain,openjpeg,v$(OPENJPEG_VERSION))
    package/python-coherence/python-coherence.mk:PYTHON_COHERENCE_SITE = $(call github,coherence-project,Coherence,Coherence-$(PYTHON_COHERENCE_VERSION))
    package/python-crc16/python-crc16.mk:PYTHON_CRC16_SITE = $(call github,gennady,pycrc16,v$(PYTHON_CRC16_VERSION))
    package/python-pysendfile/python-pysendfile.mk:PYTHON_PYSENDFILE_SITE = $(call github,giampaolo,pysendfile,release-$(PYTHON_PYSENDFILE_VERSION))
    package/systemd/systemd.mk:SYSTEMD_SITE = $(call github,systemd,systemd,v$(SYSTEMD_VERSION))
    package/unionfs/unionfs.mk:UNIONFS_SITE = $(call github,rpodgorny,unionfs-fuse,v$(UNIONFS_VERSION))
    package/yaml-cpp/yaml-cpp.mk:YAML_CPP_SITE = $(call github,jbeder,yaml-cpp,release-$(YAML_CPP_VERSION))

So some did manage to sneak in; about half of them when the github
helper was introduced.

> So I'm not sure why we would want to do this differently for the poco
> package. Yes, poco-poco-1.7.2-release seems weird, but if you find this
> weird, then it's upstream who should change the name of their tags.
> 
> That being said, one thing that might lead us to change our mind is
> when we will do tracking of new upstream releases. In this situation,
> it might be easier to have a "cleaner" <pkg>_VERSION variable. See for
> example the list of versions visible at
> https://release-monitoring.org/project/5418/.

I think there are so vicious^Wvarious ways to put tags, tht we can't
even consider this for now...

So, until we have a good reason, let's stay with the version as-is for
now...

Regards,
Yann E. MORIN.