prop2gcc?
rjo__
Posts: 2,114
Howdy,
I have less than an hour a day at this point... am bouncing around quite a bit. So, it is easy to forget what I barely understood in the first place.
Any help would be appreciated.
I'm on a Mac. I have a bare de0-nano and a project that I think is perfect for the P2. My options are to dive in or start doing what I can on the P1.
Where do I put prop2gcc? Is there a tutorial available or very basic description of how to use it? Is it possible to use prop2gcc with SimpleIDE?
Thanks
Rich
I have less than an hour a day at this point... am bouncing around quite a bit. So, it is easy to forget what I barely understood in the first place.
Any help would be appreciated.
I'm on a Mac. I have a bare de0-nano and a project that I think is perfect for the P2. My options are to dive in or start doing what I can on the P1.
Where do I put prop2gcc? Is there a tutorial available or very basic description of how to use it? Is it possible to use prop2gcc with SimpleIDE?
Thanks
Rich
Comments
http://code.google.com/p/propgcc/downloads/detail?name=prop2gcc-mac-2013-05-17.tar.bz2&can=2&q=
I believe it is possible to use this compiler with SimpleIDE although you might have to manually add the -mp2 option to get it to generate P2 code. Steve will probably comment with better information about SimpleIDE.
Can't type on the Mac right now. Prop-GCC installs anywhere. I need to update the GCC docs with build notes. Forgot about that.
Anyway, those notes are here and I will find them to link. Once you put PropGCC on your Mac, and you set permissions so it runs, you just need to get your path set. That takes care of command line operation. Steve can tell you the SImpleIDE specifics.
A clevel symbolic link or two would work, but there is likely a setting you can change to point SimpleIDE to your PropGCC. I put mine in my user directory. /users/me/parallax/propgcc
Had no trouble building things as a user once I had the path set right. Doing this on a Mac is different from Linux.
You make a file containing the path to PropGCC into /etc/paths.d . Gotta be root for that. I used something like "sudo echo "/users/me/parallax/ppropgc" (greater than symbol I can't seem to type on this phone) /etc/paths.d/propgcc
dgately
10.6.8
That should be enough to get me started... about an hour later I'll be back:)
SimpleIDE didn't like it saying that it had quit, but the environment stayed active. My project passed build but everything else flagged an error(1).
I then pointed the compiler field in Properties to /opt/parallax/bin/propeller-elf-gcc-4.6.1 and changed the permission to everyone read/write.
Same result.
There is no hurry on this... I've got Special Olympics bowling tonight:)... for my son.
BTW) I run the Linux version on Fedora. You need to update the bin path within the '.cshrc' by ...
...or whatever your corresponding bin path location is.
set path=( {Your bin path here} $path )The path is built from the contents of files contained in /etc/paths.d Every file in there should be named with the name of the application it contains a path for, and the file should contain the path on one line. Path order comes from the filenames too.
On Mac OS, you can add something like a .bashrc in your home, and it will be read and processed, but doing this is non standard. Other programs / GUI tools may or may not see your path as intended if it's not in /etc/paths.d Just saying.
You should be editing a .profile file within your home directory. That's so it will work with whatever shell you use.
Here's an example of a portion of my .profile file. It includes paths that allow propgcc as well as catalina to be run. And, there's a bit of code to get color prompting in the Terminal app (just for fun):
# color prompt PS1="\[\e[0;31m\][\[\e[1;31m\]\u\[\e[0;34m\]@\h \[\e[32m\]\w\[\e[0;31m]\]\$\[\e[0m\] "; # PropGCC Programming PATH export PATH=${PATH}:/opt/parallax:/opt/parallax/bin # Add path to catalina propeller compiler export PATH=/usr/local/lib/catalina/bin:/usr/local/lib/catalina/include:/usr/local/lib/catalina/lib:$PATHAdd this to a file named .profile in your home directory (i.e. /Users/yourUserName/)... Each line that exports the PATH variable will add to it. To see all of your environment variables, type:
$ printenv
dgately
If your path is /opt/parallax/bin and your application is propgcc, then you do this: sudo echo "/opt/parallax/bin" > /etc/paths.d/propgcc
Using the home directory profile works just fine. I didn't mean to imply that it didn't, because it does. It is however non standard. The above method is supported by Apple, and that's the assumption the Apple user environment and applications makes. YMMV.
I won't say don't do it the other way, because I did lots of times. When building PropGCC for MacOSX this last time, I decided to go and look up some basics. Environment variables get set through files too, for what it's worth. Maybe I'll write that up another day another thread.
This is idiotic behavior, but it is apple :-)
All applications have to do is pull from the environmental variable itself.
On windows or linux that is a simple mouse right-click and select all in build status.
On mac that is a CTRL+click and select all in build status.
Adding special things in SimpleIDE for the P2 build is not even on my radar right now. That may change in a few months.
I like using the .profile method as I can just copy that file to another CPU or home directory, without the need to remember and rerun the echo commands. Other programs can see those paths as well so there's no loss. It may not be the prescribed method, but it's a bit of old-school that works for me. I may take up the use of paths.d in the future, but I'll probably keep a file in my home directory of all the paths for memory's sake :-)
As far as Apple and idiotic behavior (speaking to __red__) I'm not sure of what's implied. The behavior of using .bashrc & .profile comes from a long line of Unix use, long before Apple based its OS on BSD Unix.
dgately
.bashrc and .profile are the correct way of doing it. What I was calling idiotic was this:
Your .bashrc, .profile, .cshrc etc etc should all be honored all the time. Diverting from that, as you put it "long line of UNIX use" is what I have the issue with.
However, there are a few kinds of Apple users.
Some won't ever have this discussion. They want it to just work, and Apple has done the work to make that a potential reality to a degree they find valuable. We can ignore them.
There are more advanced Apple users. They still want it to just work, but they are willing to get into the computer on a level beyond the well managed environment it presents. But, they are Apple users and they believe in the Apple way, which isn't the Unix way. The way Apple sees it, UNIX is just a component to a much larger solution. They want to manage that from top to bottom, and that's where Apple adds a lot of value most other computer vendors do not. Not everybody sees this as value, but it's there. These users are the ones that want to know how Apple does things on Mac OS X. It's UNIX, plus some stuff. To them, non-standard things like setting a profile, or .bashrc, etc... is cruft that is extra. Cruft that might break in a future OS X due to the fact that Apple treats UNIX as a building block toward some greater end.
Then there are the rest. They see Mac OS X as just another UNIX, and they tend to see all the stuff Apple did as getting in the way of UNIX. The conflict is between the Apple way and the UNIX way, two very different things with very different intents and scopes of influence.
My intent here was to just note the Apple way for those people who want to use their Mac with that in mind.
Honestly, I think Apple needs to do what they need to do in order to add value the way they normally do. This can, will and has conflicted with the UNIX way and it's unavoidable. I don't think anything about that is a huge deal either. What will happen is using a Mac in the classic UNIX way probably will conflict with some update or other. It already has a time or two in my experience as the OS changes. It's worth knowing how to avoid that and what's standard on the OS and what's not.
/etc/paths/d and the registry like file structure that contributes to the system environment do result in those values being present in the environment. So, a properly written UNIX application will see the environment as intended. I don't see Apple messing with this. What they've done is change how that environment gets built, and they've done it that way to compartmentalize the changes needed to integrate applications and their environment needs so that files don't need to be edited, instead they can be simply deleted or moved. Additionally, changes in the form of edits are easily constrained to those things related to an application or subsystem where file edits can break the OS when somebody doesn't know what they are doing.
Given the kinds of Apple users out there and the differences between them and Linux / UNIX users, this is perfectly rational. An application vendor can drop what they want into the system by merely copying files, leaving the rest alone. That's the Apple way, and it goes way back. It's just not the UNIX way. Everybody owns their part of things in ways that keep some mistake or problem from breaking what Apple did, and it's important to Apple that things don't break and that users don't have to know much to use the computer.
I support a high end CAD application. When it was first released, it was released in the UNIX way, which assumed a lot of things that were simply not true on Mac OS. People would install it, then remove it, then experience trouble with either a reinstall, or conflict between the UNIX way and the Apple way.
I ended up learning something about the Apple way and spent time educating people on the UNIX way. Notable experience, if a bit painful.
That application is now changed, and the overall experience is much better. A few of us had some long and interesting conversations about this, the highlights of which I'm putting here.
Regarding application specific environment variables, there is the ...library/com.apple.whatever file structure. Rather than make a monolithic registry mess like Microsoft did, and rather than have files sprinkled all over the place which everybody did some of, Apple made a structure for this, splitting the middle. The norm outside of the ugly Microsoft registry was to put editable files in with application files. Well, increased security needs and the overall danger of user edits in that space warranted something else, and that's the kind of thinking that goes into these things, for what it's worth.
I'm not a particularly loyal Apple user. The UNIX way works for me as it always has. However, when I'm on an Apple UNIX, I've come to understand it in ways very similar to how I did on SGI IRIX, which featured a few of these same kinds of things, and notably both Apple and SGI presented absolutely excellent user GUI experiences and tools. I think it has some merit on that basis as "The UNIX way" has rarely produced cohesive GUI environments that do what both Apple and SGI did on their machines. Doing that takes some management of the whole thing beyond the bare nubs normally seen in UNIX land.
And my overall support it experiences have shown me the value of at least understanding and complying with "the vendor way" where possible. One primary driver of this today is the ugly frequency of updates seen on just about everything. Knowing what could get touched, who manages what and where can save considerable time and money and mental anguish, that's all. And that was my intent here.
I agree that diverting from the time honored use of those files would be dumb. But as I know it, Mac OS X still works well with this "old" method :thumb:
dgately
Sorry.
I broke something. After reinstalling I get
Thanks. I would like to work inside of SimpleIDE but if that is premature, I can figgure the command line:)
I now have propeller-elf-gcc-4.6.1 in paths.d.
I had to use sudo -s before the sudo echo command to get permission.
Rich
It doesn't load, but that's probably me?
Thanks... if i use the -p option, the build status says that I'm using GCC 4.6.1 and the build succeeds.
If I use the -mp option it says
I'll upgrade to Lion tomorrow and see if that is the issue.
Thank you very much.
Rich
Have you tried the version in my signature? That one is a bit old. I need to build it again and will, but it does compile for P2. It includes p2load, FYI.
Either get an early build from someone here or wait for a release that does support Propeller2.
I cannot say how much I appreciate your efforts and the fine work of everyone involved. I would not have bothered you except that I was exorcised by the thought of Arducam, which is not actually open and which is so limited compared to what should be available from the P2. Arducam is such a perfect irritant, that I actually wished that for a moment I could be Andy Lindsay.
If anyone would forward a functioning link to the future, I would definitely appreciate it and promise to give it my best attention...which frankly isn't that good:)
God Bless.
Rich
That one is a V1_0_0 build I did on my Mac when it was working. Got parts from Hong Kong today, so maybe it will be working here in the near future. The moment it is, I'll do a current build for Leopard. (10.6.8)
You should be able to download those, extract them, set permissions and build P2 programs. I used that build on my Mac to test some C code Baggers wrote here a while back. P2Load is included. Just search the directory you put it in to find it and include in your path.
In any case, the builds found at that link were from the source repository and were done with the official scripts. On Mac OS, it's difficult to build for older OSes, which is why I did them. When the Mac runs again, I'll do more current ones.
The hardest parts of building propeller-gcc are:
1) getting the repository (need mercurial ... hg clone)
2) ensuring all required tools are installed (see wiki)
3) waiting for the build to finish on windows (single threaded msys/mingw used for build only)
I don't recall having too much trouble on MAC except for getting the command line native gcc (clang). My Mini has a quad-core, so I use ./jbuild.sh 6 rm-all and it's done in about 12 minutes. The windows build can't be done in parallel (must use ./jbuild.sh 1) so it takes a few hours.
I just finished building propgcc on the Raspberry Pi.
It took something over 20 hours!