Another thing the E::B has is a location in the tool chain setting for the hex tool.
The hex tool is needed by many Embedded Compilers.
Hex tool converts object code (Binary) to hex code (ASCII).
Link to images http://community.silabs.com/t5/32-Bit-Discussion/Em-Blocks-IDE-with-EnergyMicro-support/td-p/107147
I think inclusion of the hex tool won't be a good idea because it doesn't have a standard among compilers. Take AVR for example, there are many post processing steps to separate the object file (.elf) into output files program, eeprom, fuses, lock bits, signature etc... That is not the case for i.e. PICs so how would the hex tool behave for each compiler will complicate the things much more than it should imo. I vote on post processing for hex tool.
As far as I know we have syntax highlight for asm files.
Syntax highlight is a job of scintilla, so if your asm variant isn't supported then post a bug report to them.
After they make a lexer for it we can easily expose it in the options.
If it is supported by scintilla and it is not exposed, please say so and I'll expose it (it is pretty trivial task).
I think that would be more than enough for the editor support of assembler files.
About separate options:
What king of options?
Do you want to have check boxes with the most common options?
We could probably add another tab in Build options -> Compiler settings (next to the tab "Other options").
How often do you edit asm files by hand in the embedded world?
In the desktop/server world people (almost) never need to do it.
For separate options I was thinking about the lines of assembler flags (yeah checkboxes would be nice) to be inserted directly into the assembler command line.
For the tab position why not add it next to 'Compiler settings' and 'Linker settings' as 'Assembler settings' in 'Build options'? It would be nice to make use of flags, other options and defines for the assembler too just as the compiler.
I edit assembler files for a couple of reasons in my embedded work. First to see what the compiler is generating in case I suspect a compiler bug, second to create optimized routines in case I am in a very narrow time window to perform that routine, third to code general purpose hand optimized libraries specific to my needs. These are some usages I can think of in the first place but as I mentioned in the other topic, I don't think assembler usage is that little in the desktop world judging by the fact that even I know a couple of assembler gurus from school and work despite me being a no desktop programmer at all.
As far as you probably know it is not problem to add asm files to the build system http://wiki.codeblocks.org/index.php?title=Adding_support_for_non_C/C%2B%2B_files_to_the_build_system
Probably we can add asm support for specific compilers in the trunk version of C::B.
Can you provide patches for the compilers you're using?
I am aware of that method to add support for non C/C++ files in the build system and I've been using it if needed. But I don't think that would be a comparison to native support of assembler files because it is hard to use and customize.
Please forgive my ignorance, what kind of patches do you need and for which compilers? Patches for compilers that have an assembler included?