I agree, maniacbug. I'm not sure that it necessarily makes sense for the non-IDE build processes to do all the pre-processing. If someone wants to use standard Makefiles, etc. maybe it makes sense to use standard .cpp files and syntax too, with the Arduino libraries and board.
I think that the "IDE" really should be thought more of a tool that either runs
as a full fledged IDE in a GUI mode or a non GUI mode can do all the same stuff
as the GUI mode through command line options.
So I believe that when the IDE executable is called form the command line in non-GUI mode,
that it will have to do everything the same
otherwise you will not be able to build everything that is out there, "as is".
And if you can't build everything from the command line that you can build with the GUI IDE, what is the point?
Much of the problem is that the existing code, libraries and even the core code are "decaying" into "Arduino-ized" code
rather than standard C/C++ code because they are being built after the IDE massages things.
As such, the only way to build the code is to do all the same pre-processing that the current IDE does to ensure
that the code can be built.
My preference would to be simply have the IDE executable be able to take command line arguments which
includes options like -o to specify the output file names.
That way, a real Makefile sitting on top can create .ino to .o rules and use IDE in non GUI mode to do the build
for that module.
There also needs to be a way set/over-ride compiler and linker options so that more sophisticated
users can do things like use source level debugging.
One of the more painful things in the current IDE is the way include paths are handled.
The way things are currently done it makes it difficult for one library to be able to directly use another
There are some simple alternate ways of doing things to easily clean this up in a transparent
and yet backward compatible way.
But in order to do these kinds of things, the Arduino team needs to be more open to ideas, outside
their own core development team.
There are folks out there with literally decades of realtime embedded development experience who
really do understand what it takes to build real products and could offer the core
team ready-to-go solutions, if the Arduino core team were simply more open to outside