I'd also like to write a Makefile to compile the lib under linux and mac.

I'd rather avoid this if possible . . . if not, perhaps just like sys files we can also have OS files. Just put in a header file for your selected OS. No header file defaults to Windows.

Or something like that - Webbot usually has better ideas than me for this!

I'm not sure to understand what you mean here :p

I just want a way to compile the lib under Linux, nothing specific to linux here. Right now there is nothing to build the lib without WinAVR :p

Chelmi.

I currently build the library from a command line - but using Ant - which non-Java folk probably wont know about.Equally I tend to build my 'example' files (unpublished so far) using Ant as well.

But when working on a given project I tend to use AVRStudio or Eclipse IDEs

So I don't really tend to use C makefiles much. But I'm sure that others do.So it would be great if you were willing to contribute say:1 - A generic makefile for an end application that just uses the lib (ie one C file, many H files, + the lib)2 - A generic makefile to build the library itself. Hopefully one that will cope, unmodified, with any new *.c files and also allow the whole lib to built for various different mcus and clock speeds.

"If" you understand Ant then I can send you (or you can get from CVS) the build.xml that builds my library across each target processor - which may be of help.

I'd also like to write a Makefile to compile the lib under linux and mac.

I'd rather avoid this if possible . . . if not, perhaps just like sys files we can also have OS files. Just put in a header file for your selected OS. No header file defaults to Windows.

Or something like that - Webbot usually has better ideas than me for this!

I'm not sure to understand what you mean here :p

I just want a way to compile the lib under Linux, nothing specific to linux here. Right now there is nothing to build the lib without WinAVR :p

Chelmi.

I currently build the library from a command line - but using Ant - which non-Java folk probably wont know about.Equally I tend to build my 'example' files (unpublished so far) using Ant as well.

But when working on a given project I tend to use AVRStudio or Eclipse IDEs

So I don't really tend to use C makefiles much. But I'm sure that others do.So it would be great if you were willing to contribute say:1 - A generic makefile for an end application that just uses the lib (ie one C file, many H files, + the lib)2 - A generic makefile to build the library itself. Hopefully one that will cope, unmodified, with any new *.c files and also allow the whole lib to built for various different mcus and clock speeds.

"If" you understand Ant then I can send you (or you can get from CVS) the build.xml that builds my library across each target processor - which may be of help.

I can pull the latest CVS and compile on a mac (Snow Leopard) with ant. I did not need to install anything special besides xcode and the avr package (CrossPack-AVR-20090415). I did have to remove some chips that my compiler didnt know about from the build.xml but that was painless to do.

1. Compiling WebbotLib itselfThere isn't really any reason why you would want to do this. The *.a files are 'pre-compiled' versions of the library. Its done for you.The only other reasons you may choose to build the library are:-a) coz you've changed the library source (and you known what you are doing!). The preferred solution is to use Apache Ant. Thats what I use. Doesn't need a GUI, and is supported on all the Java platforms (so Win/Unix/Mac etc). Other folk on this thread have used it as well. Note that if you come up with your own build process / makefile then I cannot support your output - I only support my code and build.b) coz you are trying to add a non-supported mcu. Believe me it aint worth it. I can do it in 10% of the time - or tell you why it cannot be supported. Believe me - if I see emails that it doesn't support 'my home made support for the Milton Keynes ATMega123 processor' then I may just fall asleep.

2. Compiling your applicationA makefile for a project application is a very valid thing to require. Mainly coz those poor Mac folk (you know - the guys that tell you that the Mac can do anything 10 x better and easier than a PC!) cant use a simple app like AVRStudio . So we PC folk have to help them to create a makefile script so that they can run it mainframe/batch mode. So I have attached an example. Although IMHO a makefile is just SOOOOO inflated with all sorts of useless rubbish. (Ok so now I've annoyed all Mac users and all C programmers. Uhmm! You guys really need to get hold of Ant!).

hi Webbot.out of interest,what is in your ant build.xml file? any chance of a link to where you got it?

i've been reading up on ant all day but am unable to find much on building C applications with it. everything i've found so far has been either very dated or aimed at Java.(i do keep finding misspellings of "and" in my search results though...)i'm sure i could work it out eventually but there is obviously a source of documentation i'm missing out there somewhere...

hi Webbot.out of interest,what is in your ant build.xml file? any chance of a link to where you got it?

Just open it. Where did I get it - well I just wrote it!

Quote

i've been reading up on ant all day but am unable to find much on building C applications with it. everything i've found so far has been either very dated or aimed at Java.(i do keep finding misspellings of "and" in my search results though...)i'm sure i could work it out eventually but there is obviously a source of documentation i'm missing out there somewhere...

You just have to do a mind shift. Ant is cool at executing all sorts of things during a build process.Although its aimed at Java then it can also execute external commands (ie another program like avr-gcc rather than the Java compiler).So now that you've got Ant can you rebuild the libraries by going to the WebbotLib folder and just typing:antor if you want to see all choices thenant -projecthelpwill list things like 'clean' - to delete ALL compiled code/libs etc

Yep Ant was made to make the Java build process easier. Its good for moving files around, packaging them into JARs and ZIPs etc. A lot of the tasks are Java related.

However: the big get out is the 'apply' task which allows you to run an external command. I use this to run avgr-gcc, the linker, etc. This uses the System Exec function in Java - so cant see why it wouldn't work on a mac, Linux etc. I use the 'mapper' task so that a C file is only rebuilt if it has been modified since the compiled 'O' file was generated. This is good for most purposes - but does mean that if you modify an H file. My get out is to do a 'clean' and then rebuild the lot (which is very quick anyway).

I can't see any reason why you need to load in other 'C specific' tasks. May help with the header issue above but its probably not worth the hassle.

Quote

i still haven't found anything on using ant to build C for AVRs though.

[edit]this thread is mostly noise from here on.caused by a misunderstanding.

the basic, unmodified version of ant is all that is required.

if your AVR is on the list of supported devices you do not need to do any of this.

build.xml can be found from the "Developers" tab on WebbotLib's Sourceforge page. from there got to "CVN" and "Browse Code".to here: [link]http://webbotavrclib.cvs.sourceforge.net/viewvc/webbotavrclib/webbotavrclib/[/link]

Would be interesting to see how a Mac build.xml differs from my one - since Java (ie Ant as well) are meant to be platform independent. So cant see why mine won't work straight off the bat - unless its got Windows path names in it.

I can pull the latest CVS and compile on a mac (Snow Leopard) with ant. I did not need to install anything special besides xcode and the avr package (CrossPack-AVR-20090415). I did have to remove some chips that my compiler didnt know about from the build.xml but that was painless to do.

The big benefit of Ant over a 'makefile' is I can add new source files and Ant just does it - whereas for a makefile I have to add them all in by hand. Pain. The Ant build.xml file also builds each CPU library seperately or all in one go. I hate makefiles !!

No no no. You will never find a version of Ant or its tasks that are aimed at AVR and it has nothing to do with build.xml which also is completely non-platform dependent. You are trying to make this overly complex!!! Aargh.

The build.xml is read by Ant. It sees an 'apply' task. It runs that program. The fact that avr-gcc is reading text source files and outputting another file (compiled stuff) is of no interest to anybody. Ant doesn't care, build.xml doesn't care. All they care about is that one file goes in and another comes out.

The compiler 'avr-gcc' is aimed at ATmel AVRs - ie its a cross compiler. You run it one platform (Windows/Mac/Linux etc) and it generates code for AVRs. Ant doesn't need to know anything about that - its just an an external program that executes.

We need to chat, Skype or something about this. You are making an issue of what your own computer operating system is - when its actually TOTALLY irrelevant. The only difference is making sure you have a Mac/Linux version of 'avr-gcc'. This has nothing to do with WebbotLib, Ant or anything. If you want an AVR C compiler, to host on a Mac, then you will need a compiler (for us Windows folk it comes with avrstudio). Once you've got the compiler then you can control it via the command line. Ant, via your build.xml, does exactly that.

In the same way. If you had an ftp program then Ant could probably call that program to xfer a file to a server somewhere. Wat operating system is running on that server is of no interest to anyone and changes nothing.

We really need to chat - as I think you are wasting an ENORMOUS amount of time producing your own alternative to something that I already ship in the release. And all of this to re-compile WebbotLib itself. Which is a waste of time unless you are going to contribute to the core of WebbotLib.

If you are only WebbotLib to write programs then you don't need to do anything - (no matter what OS you have on your computer).