Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] libiqrf: Bump to v0.1.2 + update build system.
Date: Wed, 3 Jul 2013 23:04:56 +0200	[thread overview]
Message-ID: <20130703210456.GE3268@free.fr> (raw)
In-Reply-To: <1372884680-14309-1-git-send-email-marek.belisko@open-nandra.com>

Marek, All,

On 2013-07-03 22:51 +0200, Marek Belisko spake thusly:
> v0.1.2 update build system from autotools to cmake.

Is it mandatory to switch to cmake when upgrading?
If not, then please split this in two: one to upgrade, one to switch.

If possible, I'd prefer we stick to using autotools if it is still
supported (and maintained) by libiqrf. I'm wary of the fuss around
cmake (but agreed, that's a personal taste). Every now and then, I
pester at cmake usage, since I don't really want to pay the price for
Yet-Another-Build-System, and the very few packages that I need and
use cmake, do compile in an aggregated time much smaller than it takes
to build cmake itself.

So, my personal taste would be to favour autotools against cmake
where/if possible, please. ;-)

Note: of course, if autotools is no longer supported by libiqrf, then
the switch is mandatory, but if so, state it explicitly in the commit
message.

> Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
> ---
>  package/libiqrf/libiqrf.mk | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/libiqrf/libiqrf.mk b/package/libiqrf/libiqrf.mk
> index f2d5b4c..df4bb42 100644
> --- a/package/libiqrf/libiqrf.mk
> +++ b/package/libiqrf/libiqrf.mk
> @@ -4,11 +4,11 @@
>  #
>  ################################################################################
>  
> -LIBIQRF_VERSION = v0.1.0
> +LIBIQRF_VERSION = v0.1.2
>  LIBIQRF_SITE = http://github.com/nandra/libiqrf/tarball/$(LIBIQRF_VERSION)
>  LIBIQRF_INSTALL_STAGING = YES
>  
>  LIBIQRF_DEPENDENCIES = libusb
>  
> -$(eval $(autotools-package))
> +$(eval $(cmake-package))

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2013-07-03 21:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-03 20:51 [Buildroot] [PATCH] libiqrf: Bump to v0.1.2 + update build system Marek Belisko
2013-07-03 21:04 ` Yann E. MORIN [this message]
2013-07-04  4:51   ` Belisko Marek
2013-07-28 14:05 ` Thomas Petazzoni
2013-07-28 19:38   ` Belisko Marek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130703210456.GE3268@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox