I know variations on the question of using an assembler with Code::Blocks have been asked many times and the response is usually to look at:
http://wiki.codeblocks.org/index.php?title=Adding_support_for_non_C/C%2B%2B_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)
The solution from that page is basically what I'm currently trying, but it doesn't seem to help with passing different arguments to the assembler for debug (currently only /Zi) and release (currently empty) targets. To get around this I've added compiler variables DEBUG_MASM_OPTIONS="/Zi" and RELEASE_MASM_OPTIONS="" and am using the following macro as suggested in the link above (split into several lines here for readability):
ml64 /nologo
[[ if ( GetProjectManager().GetActiveProject().GetActiveBuildTarget().Matches(_T("Debug")) )
{ print( ReplaceMacros(_T("$(DEBUG_MASM_OPTIONS")) ); }
else { print( ReplaceMacros(_T("$(RELEASE_MASM_OPTIONS")) ); } ]]
$includes /Fo$object /c $file
That works, but it seems complicated to me. Is there an easier way to get different options for different target types with non C compilers?
For sure you can simplify this if you use a single variable MASM_OPTIONS. I'm not a user of this feature, but I would expect it to work out of the box. If it doesn't I'll make sure it works, so please test and report.
I'm talking about code like this:
print(ReplaceMacros(_T("$(MASM_OPTIONS")));
I would also expect that just placing $MASM_OPTIONS (in the correct format for expansion of course) should be enough, but I'm not so sure and probably this doesn't work. I guess we called ReplaceMacros only on parts of the command and not on the whole command...
I tried changing the compile command line macro to:
ml64 /nologo $(MASM_OPTIONS) $includes /Fo$object /c $file
like you suggested, but the only way I could think to have it give different values in different targets was to define it as custom variable like shown in the attachment. Is that what you meant? That does work as well, but if I do it that way I guess I have to set a MASM_OPTIONS variable in every project where I add assembly files. That's not too bad, but what I had before, while more complicated, could be set once. Or is there another way to get the MASM_OPTIONS variable to have different values in different targets?
One other thing. If I don't set MASM_OPTIONS to be an empty string in the Release target, when building in release mode, the build process will find the "/Zi" from the Debug target and use that. I wasn't expecting that value. I thought it would evaluate to an empty string if it wasn't defined in the target being build or at the project level. Is that the intended behavior of the custom variables?