Please find attached an updated ebuild and associated patches for prc-tools 2.2. This package is a set of compiler tools for the PDA's running PalmOS. The tools included are gcc, gdb, binutils, and make. It supports both m68k and ARM. It also has a patch to support multisegmented debugging. I've included the previous 2.1 ebuild that moves the info files from /usr/share/info to /usr/share/info/prc-tools so they won't overwrite gcc info files. I would suggest the category dev-palm, although sys-devel would work as well since that's were gcc is stored. Enjoy! Pat
Created attachment 3859 [details] prc-tools 2.2 ebuild (Updated Package)
*** Bug 7164 has been marked as a duplicate of this bug. ***
I am presently reviewing the package; it's not a trivial emerge but I'll let you know how it turns out.
Not trivial indeed. This is my first ebuild and it took about a week to get it right (if it is right.. :). One thing to really look at is the info files. They will overwrite the gcc info files, which is really undesirable since this package is based off gcc 2.95, not gcc 3.2. To my knowledge, there is no advantage to even reading the info files produced by this package because they are the same as gcc 2.95. If you have any questions post them here and I'll try to respond quickly. Thanks!
Okay, here's the scoop: 1) what's up with putting the html docs in /opt? those should probably go in /usr... 2) this package conflicts with existing packages. Specifically, the /usr/lib/libbfd.a conflicts with the installed version. This must be addressed somehow. The good news, however, is that we are working on bringing full cross compiling abilities to gentoo. To help us reach this goal, please rework the ebuild to build /only/ the prc-tools package, and split off the binutils and other pieces into their own ebuilds (on which prc-tools can DEPEND). This will still be an intermediate step, but if you can do that, it will help me sift through the pieces you've provided. Otherwise, it looks like great stuff that we hope to be able to incorporate. [Also, be sure to attach your files more carefully, the brief description should contain the file name - I had to guess your file was a tarball. :) This is a deficiency of bugzilla.]
On this ebuild I pretty much left the directories as they were set by the developer, hence HTML docs in /opt, etc. Those can be changed easily. I didn't realize the libraries are overwritten, not good! I'm not that familar with gcc or how all this works together (exactly) so I'll do my best. Some of those libraries probably aren't even used by palm apps, so I could discard them. As for splitting things apart, I'm assuming you mean these pieces: gcc, gdb, binutils and make? Would you recommend packages named like "prc-gcc" or "palm-gcc" ? I'll check with the prc-tools dev list, ask some questions, etc as well.
Use the 'ebuild' command to test the ebuild file, specifically: ebuild prc-tools-2.2.ebuild install will put a pre-installed image in /var/tmp/portage/prc-tools-2.2/image. In my inspection, I looked for files that were likely to conflict, and the first I found was the above mentioned libbfd.a. It is a critical part of binutils and can not be discarded, but the package must also play nice with the existing toolchain. For now, you can create all the ebuilds as prc-tools-*, and they can all live in the same directory in portage. (it's not going in until we clean this up... :) It should be 'fairly easy' to clean up all the packages to install into a completely independent trees (/usr/plamtools-safe/bin, etc...), that would be my first step even though you'll have to tweak your PATH and what to use them once installed. Please be sure to try and review every aspect of the ebuild for ideal better confuration and install settings. Remember, your ebuild may be installed on hundreds of machines, and the better packaged it is, the less I'm going to bug you about it when something goes wrong. :)
> Please be sure to try and review every aspect of the ebuild for ideal better > confuration and install settings. Remember, your ebuild may be installed on > hundreds of machines, and the better packaged it is, the less I'm going to bug > you about it when something goes wrong. :) Point well taken :) In my further ebuilds I've submitted for other packages, I did look at those more carefully, using the "ebuild ... install" option. So would /usr/palmtools/${SLOT}/ be the preferred directory, as KDE is done? I did that for the SWORD ebuild, but was told it would be better to use /usr/${P}-${SLOT}, (in this example /usr/palmtools-2). I've read through the Developer-HOWTO but didn't see the recommendation there (unless it's been added recently). Just asking questions to make sure the next interation is correct. BTW, how would this affect other Palm dev utils such as the already existing "pilrc" and "pose"? These don't conflict with anything, so putting them into /usr/palmtools isn't really necessary, but just wondering.
Created attachment 5489 [details] prc-tools.tar.gz : prc-tools ebuild into /usr/palmtools/2 This is one ebuild that installs everything into /usr/palmtools/2 and an entry in /etc/env.d to get the path right. It works for fine. I haven't separated out the bintuils/gcc/gdb/make etc yet because the prc-tools distribution has a build procedure that does all at once and I'd have to break this apart. If you still would like things this way I still attempt to do so.
I will proceed to test your new ebuild and, if everything looks good, I will try to get it in before the end of the weekend. Thank you for putting in this extra work. I will get back to you regarding further seperating the ebuilds; such seperation is the Right Thing to do, but it can happen at its own pace.
after looking at this further, this ebuild can't be commited as is. First, gdb-5.0 is no longer available from the redhat site listed in SRC_URI. I tried updating to 5.2.1 (the latest), but there are problems with applying the patches. Second, the more I look into this ebuild, the more convinced I become that the ebuilds need to be split off. In effect, the diffs and build commands need to be integrated with their respective ebuilds. The trick will be to do this in a SLOTed and platform specific manner. Look at the new gcc-config and gcc ebuilds to see how they setup for cross compiling. This only scratches the surface, but it's the direction the distro is moving. Further tools will be need to manipulate the entire environment, and the existing gcc-config will likely need to be adapted. If you would like to help contribute to the cross compiling work, try to visit #gentoo-dev or #gentoo-arm and find either karltk, myself, or others. But until the general case has been mapped out, I'm hesitant to commit this uber-ebuild that tries to tackle the jobs of all those other ebuilds.
Thanks for looking at it. I will try to look at the newest gcc-config and gcc. I really don't have any experience with configuring gcc, binutils, et all. This ebuild has been constructed basically from the RPM spec file at http://sourceforge.net/project/prc-tools. The entire build process is part of the project, I only got the sandbox errors to go away and moved the install directory, so I can't promise anything. If I do get things split apart I'll submit new bug(s).
