Hi Attached are 10 ebuilds for cdk4msp. CDK4MSP are a Cross Development Kit for the Texas Instruments MSP430 MCUs. The ebuilds installs the binary rpm packages for i386 avalible at the cdk4msp homepage. (See the URL field.) The cdk4msp-0.2.ebuild installes only a few shell-scripts, which should be sourced in the users ~/.bashrc or similar. It also acts as a "virtual" package, depending on all the other nessesary packages. Two use-flags are used, parjtag and serjtag. Depending on which use-flag are set, either cdk-msp-isp-parjtag-20031104.ebuild, cdk-msp-isp-serjtag-20031104.ebuild or both are installed. (When installing the cdk4msp ebuild.) I hope my work will reach portage. Thanks. ;)
Created attachment 97639 [details] cdk4msp-0.2.ebuild cdk4msp-0.2.ebuild Main ebuild
Created attachment 97640 [details] cdk-msp-binutils-20031106.ebuild binutils
Created attachment 97641 [details] cdk-msp-gcc-20031106.ebuild msp-gcc
Created attachment 97642 [details] cdk-msp-gdb-20031106.ebuild msp-gdb
Created attachment 97643 [details] cdk-msp-isp-20031104.ebuild msp-isp
Created attachment 97644 [details] cdk-msp-isp-bsl-20031104.ebuild msp-isp-bsl
Created attachment 97645 [details] cdk-msp-isp-parjtag-20031104.ebuild msp-isp-parjtag
Created attachment 97646 [details] cdk-msp-isp-serjtag-20031104.ebuild msp-isp-serjtag
Created attachment 97647 [details] cdk-msp-jtag-lib-20031102.ebuild msp-jtag-lib
Created attachment 97648 [details] cdk-msp-libc-20031102.ebuild msp-libc
It would be great, if kernel options for the parport is informed under install. And why not use the srpms?
Including information about which kernel options should be enabled would be nice, but I don't think it is that important. Besides it depends on whether you want to program the msp via the parallel port, serial port, use the network proxy or even just want to cross-compile and perpaps transfer the executeable in some other way. The srpms contains two things, a clean copy of the original project (gcc, gdb, glibc, and so on) and some patches porting it to the msp. If i where to install the (patched) srpms without any other modifications, they would overwrite your /usr/gcc, /usr/gdb and the like. And I don't think you would like your default gcc to compile for the msp. The rpms installs into /opt/cdk4msp, and you are able to source /etc/cdk4msp.sh which adds /opt/cdk4msp/bin to your path (and some other things). That way you can choose when you want to compile for the msp. (It provides msp430-gcc, msp430-gdb, msp430-ld and so on in your path.) If you really want to use the srpms, you're welcome to modify mine or create your own ebuilds. I have a few somewhat finished ebuilds that use the srpms, but they currently overwrite your normal build system (as described above). I can provide them for you if you want?
We need the package cdk-msp-gdb-proxy and cdk-msp-insight. cdk-msp-insight should block cdk-msp-gdb. Maybe I will create these later, but don't have time now...
Created attachment 98755 [details] dev-embedded/cdk4msp-0.2 The cdk4msp ebuild depended on all the other ebuilds, so it would function as a virtual ebuild. But the other ebuilds depended also on this ebuild, which created a circular dependency. When you emerged one of the ebuilds, all the other ebuilds would get emerged too. When adding the cdk-msp-insight ebuild which is blocking the cdk-msp-gdb ebuild, it wasn't possible to emerge anything. Anyway, to make a long story short: I removed the dependencies from this ebuild and some other/new ebuilds will arrive in a moment.
Created attachment 98758 [details] dev-embedded/cdk-msp-gcc-20031106 Corrected a permission error in the installed files.
Created attachment 98761 [details] dev-embedded/cdk-msp-gdb-20031106 Made the ebuild block dev-embedded/cdk-msp-insight (which will be attached in a moment.)
Created attachment 98762 [details] dev-embedded/cdk-msp-gdb-proxy-20031106 New ebuild for dev-embedded/cdk-gdb-proxy.
Created attachment 98763 [details] dev-embedded/cdk-msp-insight-20031102 New ebuild for dev-embedded/cdk-msp-insight-20031102.
Created attachment 98767 [details] dev-embedded/cdk-msp-insight-20031102 Corrected a wrong dependency.
Hi, I would be definitely nice to have msp430 support in portage, I have however a few comments: - msp-gcc should be built with crossdev see #159213 - msp-gdb gdb-proxy (msp-insight ?) too - msp-binutils is already in crossdev no need to add duplicated functionality in portage, if however they are compatible ... - all the remaining stuff should be built from sources ... It's probably a lot of work but all this should be handled the Gentoo way ... I would suggest that before we get suitable support for msp430 into portage those ebuilds could find their way into an experimental overlay, such that people who need msp toolchain support can actually have something usable ? Tinyos needs it for telosb motes it would be a nice add ... I will do some testing asap ... Bjarke to you use CDK4MSP for tinyos/berkley motes or something completely different ? Aurélien
Hi Aurélien I'm primarily using cdk4msp for custom software/kernels. What would have to be done to do this the "Gentoo way"? (What can I start doing?) Greetings
(In reply to comment #21) > Hi Aurélien > > I'm primarily using cdk4msp for custom software/kernels. Ok, it seems it actually does not work with tinyos/nesc (it needs support for "$" in identifiers in binutils ...) > What would have to be done to do this the "Gentoo way"? (What can I start > doing?) well the 4 items in comment 20 is a good start ... well that's a lot of work ;) cheers, Aurélien
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Heuristics show that no Gentoo developer has commented on your ebuild. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq