Author Topic: Using MASM and Visual C++ with different options for Debug and Release targets  (Read 202 times)

Offline New Pagodi

  • Multiple posting newcomer
  • *
  • Posts: 20
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

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):

Code: [Select]
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11200
    • Travis build status
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:
Code: [Select]
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...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline New Pagodi

  • Multiple posting newcomer
  • *
  • Posts: 20
I tried changing the compile command line macro to:

Code: [Select]
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11200
    • Travis build status
Is that what you meant?
Yes. I though you have more complex per target options.

... 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?
What version are you using? I think we change this recently and it should work correctly now in trunk.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline New Pagodi

  • Multiple posting newcomer
  • *
  • Posts: 20
What version are you using? I think we change this recently and it should work correctly now in trunk.

I'm using the August 15th, 2018 build since the October build had problems with cpu usage.  So I guess the older build didn't have those changes yet.  Thanks for your help.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11200
    • Travis build status
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]