All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Pre-RFC: clean integration of unclean packages
Date: Mon, 5 Dec 2011 10:46:38 +0100	[thread overview]
Message-ID: <201112051046.38674.arnout@mind.be> (raw)

 Hoi all,

 [Please keep me in CC]

 I mentioned a couple of months ago that I was trying to integrate TI's SDK's for accessing the accelerator hardware on DaVinci and OMAP platforms.  I had given up on that but now I picked it up again.

 I did make some progress already.  The most important step is that I found tarballs or svn repositories for all the packages that I need, so we can avoid executing a binary installer.

 A second problem is that TI uses a horrible self-cooked build system. It makes assumptions about file locations that are difficult to satisfy.  In addition, some packages don't even have a Makefile.  And finally, they generate libraries with names like 'cmem.a470MV' instead of the usual 'libcmem.a'.  To overcome all this, I wrote a custom 'Makefile.ti' that is used by buildroot instead of the packages' Makefiles.  Does everybody agree that this is a good idea, or does someone have a better suggestion?

 A third problem is that some packages depend on 'xdctools'.  This is a system to ease integration of embedded components into Eclipse.  One small part of it is a header file that defines some standard types (basically stdint.h and stdbool.h but with different names).  The whole xdctools package is a source tree of about half a gig, but for buildroot we just need this one 'std.h' file out of it...  So I decided to copy that file directly into buildroot.  Does everybody agree that this is a good idea, or does someone have a better suggestion?

 Finally, a fourth problem is that some packages assume they can directly access other packages' source trees.  To be precise: in the source code, you'll see things like #include <ti/sdo/ce/osal/Memory.h>; the Makefile adds a -I<other-src-tree> to the CFLAGS.  Now, I consider it a Bad Thing to rely on the presence of another source directory, so as a solution I just install all the header files in the staging tree.  Does everybody agree that this is a good idea, or does someone have a better suggestion?


 Thank you for your feedback!  And hopefully you'll see a first RFC for the TI libraries in a week or two.

 Regards,
 Arnout


 PS I haven't had time to keep up with the BR mailling list lately (I'm 250 messages behind at the moment), so please keep me in CC.

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111205/8aa95db3/attachment.html>

             reply	other threads:[~2011-12-05  9:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05  9:46 Arnout Vandecappelle [this message]
2011-12-05  9:58 ` [Buildroot] Pre-RFC: clean integration of unclean packages Thomas De Schampheleire
2011-12-05 10:08   ` Arnout Vandecappelle
2011-12-05 11:13     ` Thomas De Schampheleire
2011-12-05 12:03       ` Arnout Vandecappelle
2011-12-06  9:25 ` Arnout Vandecappelle

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=201112051046.38674.arnout@mind.be \
    --to=arnout@mind.be \
    --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 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.