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>
next 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox