LIbrary Aid

mindrobots

Question(s) #1

I'm not a gcc tool chain user nor *nix programmer, I cut my system programming teeth up in a different culture in a simpler time. Ths is mostly a hobby for me at this point, so I have a different perspective than a lot of the people involved in the Alpha Testing.

I'm at the point now where I want to start gathering my code snippets and commonly used routines into a library (it seems like the right thing to do in my mind) so I I don't need to do:

propeller-elf-gcc -o run.elf mainpgm.c buttons.c lcd.c xyz.c ...

to compile and link all my pieces of code together. I should just be able to compile the main (since my library code is "golden") and get it all linked together.

I've been reading and searching and head scratching most of my free time this weekend trying to figure out how to do this. Do I REALLY need to start learning about make, autoconf, automake, libtool and others to create a user library of my code?

Is this a skill I'm expected to bring to the table as someone interested in using the gcc tool chain? (if yes, this is understandable and acceptable in the ALPHA test stage)

Can someone point me to a concise source of info on how to do this generically (on Ubuntu in my case)?


Question(s) #2

Fast 6 to 12 months. Some hobbyist comes along and wants to use propgcc with their new Prop BOE and the new Parallax released Whizbang 650 Flux Capacitor. Assuming the WB650 code isn't in the released propgcc library, is there going to be an easy way for someone to pick up this new code, integrate it into the propgcc environment and start using it?

In Spin land, it's very easy to grab objects (Parallax or 3rd party) and integrate them into your development world.

From what I've seen, this library integration is a painful experience for the novice and an accepted/assumed level of wizardry for any gcc tool chain user.


If there are library integration and packaging tools that need to be built or processes that need to be documented and tutorialized, maybe this is an area in which I can help. I'm certainly this world with novice eyes wide opened in amazement with a very small assumed skillset in this environment.

Once again, if anyone can pint me to some clear info, it would be appreciated.

Up next? Memory models, multi-cogs and how to put the pieces together.

ersmith

You definitely don't need autoconf, automake, and all that sort of stuff to build a library. make and a simple Makefile will make it easier, but they're not strictly required either. All you really need is the library archiver propeller-elf-ar. For example:

propeller-elf-gcc -Os -o foo.o foo.c
propeller-elf-gcc -Os -o bar.o bar.c
...
propeller-elf-gcc -Os -o xyz.o xyz.c
propeller-elf-ar rs mylib.a foo.o bar.o ... xyz.o

Now you can build your main program like:

propeller-elf-gcc -Os -o main.elf main.c mylib.a

Note that you should always use some kind of optimization -- if you don't, the code quality goes way down. Usually you'll want to optimize for size (-Os).

As for distributing objects via OBEX and the like, in the past I think it was usually source code that was distributed (which would be portable to more compilers and allow for easy tweaking). We could also include compiled object files and/or libraries. It would certainly be useful to come up with some standards for C objects in OBEX, and so any input is welcome!

Eric

jazzed

mindrobots wrote: »

Question(s) #1
Is this a skill I'm expected to bring to the table as someone interested in using the gcc tool chain? (if yes, this is understandable and acceptable in the ALPHA test stage)

The toolchain (except for propeller as, gcc, and g++) is described here: http://sourceware.org/binutils/docs-2.21/binutils/index.html

The archive tool (propeller-elf-ar in our case) is described here: http://sourceware.org/binutils/docs-2.21/binutils/ar.html#ar

A library can be built using propeller-elf-ar.

Minimal syntax is:
propeller-elf-ar -rs libname.a file1.o file2.o fileN.o
propeller-elf-ar -t libname.s gives a list of files

Most good IDE's have a library project wizard.
You do not need to use makefiles. You can use a simple batch script with Windows if you like.

A very simple command line example would be:

// file hello.c:
int main()
{
  printit();
  printbye();
  return 0;
}

// file printit.c:
#include <stdio.h>
void printit()
{
  printf("Hello World.\n");
}

//file bye.c:
#include <stdio.h>
void printbye()
{
  printf("Goodbye World.\n");
}

propeller-elf-gcc -Os -c printit.c
propeller-elf-gcc -Os -c bye.c
propeller-elf-ar -rs printlib.a printit.o bye.o
propeller-elf-gcc -o hello.elf -Os hello.c printlib.a

mindrobots wrote: »

Question(s) #2

As far as I know and it has been discussed: Parallax Education will be using C++ syntax for their products in a similar way you can use SPIN today. Of course people don't have to use C++.

It is just as easy to provide some library mechanism for Propeller peripherals in straight C (still can be used in C++). One of the IDE ideas that I discussed with Ken Gracey early on was to have a GUI that would let users pick their Propeller Peripheral device.

Once we have reasonable progress in a GUI, we can do this. I expect that "greatness" in code and documentation with this idea will never be achieved with an off the shelf IDE package though. I could be wrong of course. Seems like a web package would be very easy to do. All one needs is a way to "pull it in" to the environment. So many things to consider, so little time .....

mindrobots wrote: »

If there are library integration and packaging tools that need to be built or processes that need to be documented and tutorialized, maybe this is an area in which I can help. I'm certainly this world with novice eyes wide opened in amazement with a very small assumed skillset in this environment.

Once again, if anyone can pint me to some clear info, it would be appreciated.

Up next? Memory models, multi-cogs and how to put the pieces together.

I would very much appreciate any help in documentation.

I can add you as a contributor to http://code.google.com/p/propgcc for making / editing Wiki pages.
Let me know if you want that.

The same invitation is open to others who show similar levels of interest and dedication to the cause.

Thanks,
--Steve

mindrobots

Thanks, Eric!

I figured I was looking at too many trees to see the forest I was getting myself into.

Yes, source distribution (as is done now) eliminates my library problem #2. I wasn't thinking clearly on this point.