From: Gustavo Zacarias <gustavo@zacarias.com.ar>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 5/5] thrift: new package
Date: Mon, 28 Oct 2013 08:02:30 -0300 [thread overview]
Message-ID: <526E4446.1090806@zacarias.com.ar> (raw)
In-Reply-To: <526E1146.2070902@mind.be>
On 10/28/2013 04:24 AM, Arnout Vandecappelle wrote:
> But not as much as requiring 80 hashes in the header :-)
Pfffft, that's not mine :)
> It's not because it wasn't done right in the past that it shouldn't be
> done right now :-)
Some licenses were defined a few days ago that weren't the last lines
before defines and nobody said anything, you should have shown up then :P
> I agree with Ryan that it would be a good idea to standardize on some
> order of the variable definitions. But since there is not standard at
> the moment, we have to wait for an edict from Peter before we can
> enforce it.
Propose it then and get it rolling, for the time being there's no rule
about it.
> That it's implicit from openssl is not really relevant - if the
> dependency is ever removed from openssl (OK, this will not happen, but
> just imagine) then we'd like to keep the correct dependency here.
Ok.
All the packages that use openssl should be checked though, almost none
of them do zlib either (doesn't mean they use it directly, but a good
check wouldn't hurt).
> It would be nicer though if that could be done with an upstreamable
> patch, but I think you said before that it wasn't going to happen.
>
> I do think that your sed magic should be done in POST_PATCH_HOOKS on
> the Makefile.am, though. Patching up the generated Makefiles just feels
> icky to me.
I don't think i've said that, but i might be wrong.
At the moment i prefer SED rather than a patch because there are many
instances around, i'll try reaching upstream to see how receptive they
are to a patch that just defines THRIFT ?= .. for a clean cross build.
It was a leftover from a quick hack to get it to build properly that
i've overlooked when cleaning up.
Fixed, i'll send a revised patchset soon.
Regards.
next prev parent reply other threads:[~2013-10-28 11:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 12:15 [Buildroot] [PATCH 1/5] libevent: add host variant Gustavo Zacarias
2013-10-25 12:15 ` [Buildroot] [PATCH 2/5] boost: " Gustavo Zacarias
2013-10-25 21:53 ` Ryan Barnett
2013-10-25 22:23 ` Gustavo Zacarias
2013-10-26 2:29 ` Ryan Barnett
2013-10-25 23:21 ` Arnout Vandecappelle
2013-10-25 23:52 ` Gustavo Zacarias
2013-10-25 12:15 ` [Buildroot] [PATCH 3/5] python-thrift: fix cross building Gustavo Zacarias
2013-10-25 21:54 ` Ryan Barnett
2013-10-25 12:15 ` [Buildroot] [PATCH 4/5] python-thrift: bump to version 0.9.1 and switch to apache Gustavo Zacarias
2013-10-25 12:15 ` [Buildroot] [PATCH 5/5] thrift: new package Gustavo Zacarias
2013-10-26 3:12 ` Ryan Barnett
2013-10-26 9:48 ` Gustavo Zacarias
2013-10-28 7:24 ` Arnout Vandecappelle
2013-10-28 11:02 ` Gustavo Zacarias [this message]
2013-10-28 14:11 ` Ryan Barnett
2013-10-28 14:21 ` Gustavo Zacarias
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=526E4446.1090806@zacarias.com.ar \
--to=gustavo@zacarias.com.ar \
--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