All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chad Versace <chad.versace@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: xorg-devel@lists.x.org, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Android port of intel-gpu-tools
Date: Mon, 16 Jan 2012 10:53:25 -0800	[thread overview]
Message-ID: <4F147225.3000604@linux.intel.com> (raw)
In-Reply-To: <20120116183604.GB3627@phenom.ffwll.local>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/16/2012 10:36 AM, Daniel Vetter wrote:
> On Mon, Jan 16, 2012 at 10:25:32AM -0800, Chad Versace wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/10/2012 04:47 AM, Daniel Vetter wrote:
>>> On Tue, Jan 10, 2012 at 10:15:01AM +0530, Sateesh Kavuri wrote:
>>>> Added support for Android. Changes include fixes for compilation issues
>>>>  related to Android using an older version of GCC compiler (ver 4.3.3)
>>>>  while the latest version of intel-gpu-tools confirms to GCC ver 4.5.2
>>>>  (C99 standard functions), using functions like getline(). Fixed such
>>>>  functions, header dependencies for android and added an Android.mk file.
>>>>
>>>> signed-off-by: Sateesh Kavuri <sateesh.kavuri@intel.com>
>>>
>>> A few comments
>>> - It looks like you need a completely separate makefile for android. Is
>>>   there no way to let the automake tools generate that somehow? Because
>>>   this simply won't scale.
>>>
>>> - There's too much ANDRIOD #ifdef'ery in the code. Either switch to a
>>>   construct that works on all platforms or extract things into a little
>>>   helper functions (like the get_total_ram helper that has recently been
>>>   ported to Solaris).
>>>
>>> - You don't seem to touch the testsuite, and I think you want it on
>>>   Andriod, too.
>>>
>>> Added xorg-devel to cc, maybe someone else has already tried this with a
>>> different package, my buildsystem fu is not up to this.
>>>
>>> Yours, Daniel
>>
>> Daniel, the Android.mk's are the curse of every project that is ported to
>> Android.  Android has it's own build system, and those makefiles can't be
>> generated with autotools.  This was a contentious issue when Chia-I Wu and
>> I ported Mesa to Android and led to a discussion [1] on mesa-dev. Below is
>> quoted my key email from that discussion (the Dan I'm speaking to is a Debian
>> maitainer).
>>
>> [1] http://article.gmane.org/gmane.comp.video.mesa3d.devel/28881/match=add+toplevel+android+mk
> 
> Meh.
> 
> I've just read about androgenizer:
> 
> http://cgit.collabora.com/git/user/derek/androgenizer.git/>
> Would that be a useful to at least generate the Android.mk in a sensible
> fashion? I don't have clue about this ...

Never heard of androgenizer, but looks interesting. When the Mesa build gets its overdue conversion
to autotools, I'll have to give it a try.

> Otherwise we'll just stick Android.mk into the root dir and I'll forget
> about this (and probably break it every time I change something).

Hah! That's expected if the Android maintainers aren't vigilant.

We've mostly fixed that problem in Mesa (when people change the "real" makefile,
the Android build breaks) by forcing the two build systems to share common
makefiles when sensible. But I don't suggest that intel-gpu-tools take that approach
unless build-breakage problems become painful.

- ----
Chad Versace
chad.versace@linux.intel.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPFHIjAAoJEAIvNt057x8ilVAQALd5Z1TSD/SfNBGp1NRTinnz
HFN17Zp56apz2bDQgC1hftkJJXNZW83IPm9lseBvpfeKLVLfxkIsp6uklPbVputK
YJdI4G7TxDWpjDxHdh/tA45q+5H6hrtsPOBcnQwfDGq99DrAI/Pt6fZAO4c/0fbe
ZYnQ42DGeAkHK/XNxvF7zrkc9gJqwYhpUp8EyuguilYmnzyMkwR2SGu8hbDGRTmc
L0dNRuArZaaaTnFWLKAWPjgTZVXg9Ah2ZEawWOlvUNmygtOoqGqtcgIsRWdxr4QR
6hRTcbmiwc6CdmR1QsdL+hHs7MPAq1Kvj5CQjjNmCefkZBleu2W7EOnyLXZmfNDM
MbUOJ79JesS7z8wEkwLgcYgas9Qj+vaHw7tWWaqLxvxXEldFCcfub+Xjf1+Vi2X4
MoZtGAyNQQ6KHPpPS/ObI4D1Ati7eQy4ZiN7ILRgjmPWj4vy+RVwlwNbC7C9yLe2
kugwJGzRePFSl6Sagf1kFymKyK0MzIfquN/7vNh/2+Z/AOR6yISPqNkoxQveXk06
PK/ee4DngWcsUxuDpYcc1/NgNLccRfddyNINxCcbz2OuwQGbhRSa9Y8dpxJeXSIR
yaElS7FFUXCaebeXur3U9KsVq+s9mDpBRRZjaPaSsoss2tWb/F1wz93Yr96QUIIq
FOZrSKKdOxM8Q+Fj0SqP
=REOX
-----END PGP SIGNATURE-----

  reply	other threads:[~2012-01-16 18:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10  4:45 [PATCH] Android port of intel-gpu-tools Sateesh Kavuri
2012-01-10 12:47 ` Daniel Vetter
2012-01-16 18:25   ` Chad Versace
2012-01-16 18:36     ` Daniel Vetter
2012-01-16 18:53       ` Chad Versace [this message]
     [not found]         ` <4F147225.3000604-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2012-01-16 19:52           ` [Intel-gfx] " Daniel Stone
2012-01-16 19:43       ` Eugeni Dodonov
2012-01-10 15:03 ` Adam Jackson
2012-01-10 16:50   ` Kavuri, Sateesh
2012-01-16 17:58     ` Chad Versace
2012-01-11  7:54 ` Kenneth Graunke

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=4F147225.3000604@linux.intel.com \
    --to=chad.versace@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=xorg-devel@lists.x.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.