What I like to do is just compile things on my local linux box (I don't
bother with a cross compiler), then I have a make target 'upbuild' which
upload to the bone and builds there.
First you compile your programs on your Linux Box. So, if your programs use something that is only available on the target board, your programs will not run on the Linux Box. You are only "checking" the syntax.
Yes. Which is all you can check outside of an emulator. But emulators are
pointless if you have the device right next to you anyway.
After, you are compiling your programs on a machine that is much slower than your Linux Box, and you need to have there all the development tools installed...
The nice thing about this approach
is you don't have to mess with a different cross compiler/IDE for
each different type of target system you work on.
When you are cross-compiling for different targets, you need to change the cross compiler, but that is easy. You usually just change a variable on a makefile, or define an environment variable….
At least one of the posts earlier (if not the whole thread) was describing
this not working this simply, and in my experience it rarely does. Theory and
practice you know.
Why do you need to change the IDE? Last time I checked, all kinds of IDEs (from vim and Emacs to Eclipse and Xcode) support different compilers and different targets.
Yes, I am calling vim an IDE because: it has syntax high-lighting, and checks the syntax when saving a file, and that's what many people want (or use) in an IDE.
I agree that vim works fine.
You need a full development environment installed on each type of target you work with.
This is possible on the BBOne, but for smaller boards, is impossible:
I use the same setup
for arduino (though you do have to use avr-gcc cross compiler there).
See my point?
No. On tiny targets you need cross-compiler, but why torment yourself
dealing with one for targets that can self-host? I target more different
boards than just BB + arduino, most can self-host. You can put something like
this in make (the only real gotcha here is the fact that ssh will denude your
recursive make invocation of MAKEFLAGS in the environment, which is
make's normal mechanism for passing them along):
# WARNING: upload deletes the BID every time it runs.
.PHONY: upload
upload: perl_syntax_ok.stamp
$(MAKE) -$(MAKEFLAGS) clean # Stop i86 binaries ending up on bone
ssh $(BBL) rm -rf $(BID)
scp -r $(shell pwd) $(BBL):
test "$(BID)" = "$(PROJD)" || ssh $(BBL) mv $(PROJD) $(BID)
.PHONY: upbuild
upbuild: upload
# NOTE: I think its ssh that's foiling make's normal strategy of
# passing make flags to submakes through the environment, so we just
# add them back in textually.
ssh $(BBL) 'cd $(BID) ; $(MAKE) -$(MAKEFLAGS) clean default'
Britton
=>