<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Incorrect compiling with &amp;#39;Release&amp;#39; and &amp;#39;Debug&amp;#39; Targets</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/41628/incorrect-compiling-with-release-and-debug-targets</link><description> 
Hello everyone! 

 
I&amp;#39;ve found myself in a spot of bother with Keil uVision 5.24.2.0
using ARM Compiler v5.06 update 5...although the build issues I have
don&amp;#39;t appear specific to these versions. Let me explain... 

 
In my Keil project I have two targets</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Incorrect compiling with 'Release' and 'Debug' Targets</title><link>https://community.arm.com/thread/121130?ContentTypeID=1</link><pubDate>Tue, 18 Jul 2017 16:57:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:62051d69-ad45-433c-9d54-c8d4bcbddac5</guid><dc:creator>Tony Stark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for the update!&lt;/p&gt;

&lt;p&gt;
1) &lt;i&gt;Because if your decision mechanism...&lt;/i&gt;&lt;br /&gt;
Okay, that makes sense! So if I do:&lt;/p&gt;

&lt;pre&gt;
#if ( DEBUG_BUILD == 1 )
#define TEST_MODE_RECOGNIZER 1
#else
#define TEST_MODE_RECOGNIZER 0
#endif
&lt;/pre&gt;

&lt;p&gt;
I pair it with conditional compilation test like this&lt;/p&gt;

&lt;pre&gt;
#if ( TEST_MODE_RECOGNIZER == 1 )
...
#endif
&lt;/pre&gt;

&lt;p&gt;
Alternatively,&lt;/p&gt;

&lt;pre&gt;
#define TEST_MODE_RECOGNIZER
&lt;/pre&gt;

&lt;p&gt;
paired with&lt;/p&gt;

&lt;pre&gt;
#ifdef TEST_MODE_RECOGNIZER
...
#endif
&lt;/pre&gt;

&lt;p&gt;
2) I think you misunderstood...&lt;br /&gt;
Indeed! I had thought the order of the different Targets is what it
meant, since it&amp;#39;s possible to re-order them. Now it is clear why
&amp;#39;Undefine&amp;#39; preprocessor symbols is grayed out at the Target level!
Can&amp;#39;t undefine anything that hasn&amp;#39;t been defined and a higher
level...and Target level is at the top!&lt;/p&gt;

&lt;p&gt;
Thanks for picking up on that one! Silly me!&lt;/p&gt;

&lt;p&gt;
3) &lt;i&gt;No. We were discussing options that you currently collect in
a global header file...&lt;/i&gt;&lt;br /&gt;
Ahh, thanks for the correction. I get it now. I should explore the
Group hierarchy more. From your explanation I realize now I could
better pair options to specific Groups; certainly options I introduce
for my modules don&amp;#39;t need to be applied to e.g. HAL modules provided
by the the manufacturer.&lt;/p&gt;

&lt;p&gt;
4) &lt;i&gt;You wouldn&amp;#39;t. You would just put the second macro itself
directly into the master Defines list instead.&lt;/i&gt;&lt;br /&gt;
I see. That&amp;#39;s easy enough for a few macros.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;As-is, your conditional chaining of debug macros does not
really gain you much anyway, compared to a bog standard, single
DEBUG_BUILD macro that you just query directly.&lt;/i&gt;&lt;br /&gt;
True. I had given an elementary example to illustrate my problem. In
reality I have several levels of debug, starting with global
DEBUG_BUILD under which there&amp;#39;s TEST_MODE under which there&amp;#39;s a list
of individual TEST_*, each with several options to enable/disable
individually. And that is just TEST_MODE.&lt;/p&gt;

&lt;p&gt;
With the conditional chaining of macros I find I can quickly and
easily control the debug output. I like I can see in the code exactly
what is enabled or disabled without having to Alt+F7 to get the
&amp;#39;Options for...&amp;#39; dialog.&lt;/p&gt;

&lt;p&gt;
But now that I understand how the Target/Group/File hierarchy
works better, I will see if it can work well for me.&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;A wish to Keil...&lt;/b&gt;&lt;br /&gt;
It would be super helpful if the Keil uVision IDE could track the
current value of #define macros (&amp;amp; values) &lt;i&gt;without
compiling&lt;/i&gt; and then apply syntax highlighting/shading in the IDE
code editor that reflects what would be compiled given the current
state of Target/Group/File preprocessor symbol Defines/Undefines (in
&amp;#39;Options for...&amp;#39; dialog) and #defines in .h/.c files.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Incorrect compiling with 'Release' and 'Debug' Targets</title><link>https://community.arm.com/thread/109244?ContentTypeID=1</link><pubDate>Tue, 18 Jul 2017 15:45:00 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c84b8a30-4b78-4124-8079-4cda56288e28</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;If so, why does this apply in my case, but not if I opted for
#ifdef?&lt;/i&gt;&lt;br /&gt;
Because if your decision mechanism do either &lt;b&gt;define&lt;/b&gt; the macro
or not, then you should check if it&amp;#39;s &lt;b&gt;defined&lt;/b&gt; or not --- and
vice versa. If, OTOH, you want to run your check against a macro&amp;#39;s
value, it should always exist, so it always &lt;b&gt;has&lt;/b&gt; a value.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;I had made my &amp;#39;Debug&amp;#39; target the highest level, where I Defined
&amp;#39;DEBUG&amp;#39;. My &amp;#39;Release&amp;#39; target is the second (and last) target.&lt;/i&gt;&lt;br /&gt;
I think you misunderstood what the &amp;quot;higher level&amp;quot; referred to by the
documentation actually means. It refers to a higher level in the
&lt;b&gt;hierarchy&lt;/b&gt; of the structured grouping of settings (i.e. further
&lt;b&gt;left&lt;/b&gt; in the usual tree view). In other words, it speaks of
outer, bigger groups, not groups that appear higher on your
screen.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Then wouldn&amp;#39;t the undefined macro TEST_MODE_RECOGNIZER still
expand to 0?&lt;/i&gt;&lt;br /&gt;
If you used it in a context where it had to be &lt;b&gt;expanded&lt;/b&gt; to a
particular value, such as your original &amp;quot;#if TEST_MODE_RECOGNIZER ==
1&amp;quot; condition, it would. But #ifdef does not expand the macro. It
really just checks if you ever #defined it or not.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;It seems cumbersome to define many macros in the Defines dialog
box like&lt;/i&gt;&lt;br /&gt;
That&amp;#39;s another shortcoming of the uVision IDE: its control facilities
for preprocessor definitions don&amp;#39;t easily support putting lots of
individual switches in there, because they&amp;#39;re all just squished into
a single line of text entry field.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;seems like I would have to set the Defines on &amp;#39;Options for
File&amp;#39; for many different files&lt;/i&gt;&lt;br /&gt;
No. We were discussing options that you currently collect in a global
header file that is meant to be included in &lt;b&gt;every&lt;/b&gt; source file
--- those options would just go into single, target-level options
dialog of your Debug target. That&amp;#39;s what the group hierarchy is for:
to collect groups of files that all get the same options.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;However, if that is the recommended way, how would I
conditionally define a macro based on an earlier defined
macro?&lt;/i&gt;&lt;br /&gt;
You wouldn&amp;#39;t. You would just put the second macro itself directly
into the master Defines list instead.&lt;/p&gt;

&lt;p&gt;
As-is, your conditional chaining of debug macros does not really
gain you much anyway, compared to a bog standard, single DEBUG_BUILD
macro that you just query directly.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Incorrect compiling with 'Release' and 'Debug' Targets</title><link>https://community.arm.com/thread/94127?ContentTypeID=1</link><pubDate>Tue, 18 Jul 2017 14:45:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1bb815c8-d0c0-4e7d-a05e-916f3119b5b0</guid><dc:creator>Tony Stark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thank you very much, Hans-Bernhard, your comment #3 helped me
resolve my problem! As soon as I created an output folder for each
target I got the behavior I was aiming for.&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m still puzzled why many other .c files -- e.g. those with GPIO
config with no dependency on debug_config.h or any of the #defines --
were recompiled for the different Target build, but main.c was
not.&lt;/p&gt;

&lt;p&gt;
Also, I&amp;#39;m unsure why the &amp;#39;Undefine&amp;#39; preprocessor symbol dialog box
is grayed out at the Target level, but enabled at the Group and File
levels. This option (discussed here &lt;a href="http://www.keil.com/support/man/docs/uv4/uv4_dg_adscc.htm"&gt;http://www.keil.com/support/man/docs/uv4/uv4_dg_adscc.htm&lt;/a&gt;)
says &amp;#39;Undefine: Clears previous Define assignments that are entered
in the options dialog of a higher Target or Group level.&amp;#39;&lt;/p&gt;

&lt;p&gt;
I had made my &amp;#39;Debug&amp;#39; target the highest level, where I Defined
&amp;#39;DEBUG&amp;#39;. My &amp;#39;Release&amp;#39; target is the second (and last) target.
According to website above, it appears I should be able to Undefine
&amp;#39;DEBUG&amp;#39; for the (lower level) Release target. But, the dialog box is
grayed out...&lt;/p&gt;

&lt;p&gt;
I appreciate your other comments, also. Here is my thoughts.&lt;/p&gt;

&lt;p&gt;
1) you should usually always #define the macro in question (to 1
or 0, accordingly)&lt;br /&gt;
Good point! I will update my code to:&lt;/p&gt;

&lt;pre&gt;
#if ( DEBUG_BUILD == 1 )
#define TEST_MODE_RECOGNIZER 1
#else
#define TEST_MODE_RECOGNIZER 0
#endif
&lt;/pre&gt;

&lt;p&gt;
Hmmm...it seems you make this recommendation based on my choice to
use #if instead of #ifdef/#if defined(). If so, why does this apply
in my case, but not if I opted for #ifdef?&lt;/p&gt;

&lt;p&gt;
To be clear, if I had:&lt;/p&gt;

&lt;pre&gt;
//#define TEST_MODE_RECOGNIZER 1

#ifdef TEST_MODE_RECOGNIZER
printf(&amp;quot;Jarvis 8.9b Test Mode\r\n&amp;quot;);
#endif
&lt;/pre&gt;

&lt;p&gt;
Then wouldn&amp;#39;t the &lt;i&gt;undefined&lt;/i&gt; macro TEST_MODE_RECOGNIZER
still expand to 0? I don&amp;#39;t see how #ifdef would be more-optimal than
my not-quiet-optimal use of #if. I feel I&amp;#39;m missing something. Could
you explain a little further?&lt;/p&gt;

&lt;p&gt;
2) move all those individual, conditionally defined macros
directly into the IDE instead&lt;br /&gt;
Do you mean define the macros in the &amp;#39;Options for...&amp;#39; C/C++
preprocessor symbols at the Target, Group or File level?&lt;/p&gt;

&lt;p&gt;
It seems cumbersome to define many macros in the Defines dialog
box like: TEST_MODE_RECOGNIZER=1, TEST_MODE_JARVIS=2, etc. I don&amp;#39;t
think it will be easy to find/check/change one macro in a long list
this way...seems like I would have to set the Defines on &amp;#39;Options for
File&amp;#39; for many different files to make it manageable. And then,
perhaps I&amp;#39;d have to repeat the process for each target.&lt;/p&gt;

&lt;p&gt;
However, if that is the recommended way, how would I conditionally
define a macro based on an earlier defined macro? That is, how to do
the equivalent of:&lt;/p&gt;

&lt;pre&gt;
#ifdef DEBUG
#define DEBUG_BUILD 1
#else
#define DEBUG_BUILD 0
#endif
&lt;/pre&gt;

&lt;p&gt;
If this is not at all what you meant, could you explain further?
Much appreciated!&lt;/p&gt;

&lt;p&gt;
Best!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Incorrect compiling with 'Release' and 'Debug' Targets</title><link>https://community.arm.com/thread/85579?ContentTypeID=1</link><pubDate>Tue, 18 Jul 2017 13:30:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d8476d38-242f-46bc-a050-c2236907e16e</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
Several issues to note:&lt;/p&gt;

&lt;p&gt;
1) this way of conditionally defining a preprocessor switch
macro:&lt;/p&gt;

&lt;pre&gt;
&lt;i&gt;#if ( DEBUG_BUILD == 1 )
#define TEST_MODE_RECOGNIZER 1
#endif&lt;/i&gt;
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
is a not-quite-optimal fit for this kind of testing the
condition:&lt;/p&gt;

&lt;pre&gt;
&lt;i&gt;#if ( TEST_MODE_RECOGNIZER == 1 )&lt;/i&gt;
&lt;/pre&gt;

&lt;p&gt;
If your condition is #if instead of #ifdef/#if defined(), you
should usually &lt;b&gt;always&lt;/b&gt; #define the macro in question (to 1 or
0, accordingly). It&amp;#39;ll still work the way you do it, because
undefined macros will expand to 0 as a last-ditch effort, but you&amp;#39;ll
get flak from most code checking tools for that style.&lt;/p&gt;

&lt;p&gt;
2) having a header that relies on:&lt;br /&gt;
&lt;i&gt;which all #include &amp;quot;debug_config.h&amp;quot;&lt;/i&gt;&lt;br /&gt;
is riskier than it needs to be. It&amp;#39;s better to move all those
individual, conditionally defined macros directly into the IDE
instead, if only because it saves you from silly problems in case you
ever forget putting that #include &amp;quot;debug_config.h&amp;quot; in one header or
.c file. And it&amp;#39;ll save you from warnings about including headers
that the code doesn&amp;#39;t actually use.&lt;/p&gt;

&lt;p&gt;
3) is your real issue:&lt;br /&gt;
&lt;i&gt;However, I selected different Target, which had different Defines,
so I expected that it would recompile main.c like it did with other
files.&lt;/i&gt;&lt;br /&gt;
If you wanted that, you had better specify &lt;b&gt;separate output
folders&lt;/b&gt; for the two targets. It&amp;#39;s arguably a bug that uVision
doesn&amp;#39;t automatically do that as soon as you set up the second target
in the same project.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>