• State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 22 subscribers
  • Views 1296 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Makefile and IDE build produce different target

Doug Moore

I have written a parser to extract the amake dependencies from the final output file. I then use it with nmake to build the same source presumably in the same order since the same .lnp file is passed to the linker in the make file as is generated by the ide. The makefile build works but the target output file is different. Are there any optimizations or other issues which may be bypassed when the IDE is not used for the build?

  • 0

    I've traced it down to the fact that c166 alters the behavior somehow depending on whether the path specified for the input module is relative or absolute. I renamed ad.c to be sure the make was accessing the same file independent of the absolute and relative path, and it was. I also used an inline file like c166 @cflags.tmp to see if it might be caused by a lack of space in the environment for the longer paths but it made no difference.

    This command line produces the code sizes as shown in the listing below:

    c:\keil\c166\bin\c166 "..\CFiles\Ad.c" HLARGE INCDIR(c:\dev\c167\lx100_m_2_3_9\HFiles;c:\keil\c166\inc) DEBUG CODE PRINT(c:\dev\c167\lx100_m_2_3_9\LFiles\Ad.lst) OBJECT(c:\dev\c167\lx100_m_2_3_9\OFiles\Ad.obj)

    CODE SIZE = 2002 --------
    NEAR-CONST SIZE = -------- --------
    FAR-CONST SIZE = -------- --------
    HUGE-CONST SIZE = 50 --------
    XHUGE-CONST SIZE = -------- --------
    NEAR-DATA SIZE = 10 --------
    FAR-DATA SIZE = -------- --------
    XHUGE-DATA SIZE = -------- --------
    IDATA-DATA SIZE = -------- --------
    SDATA-DATA SIZE = -------- --------
    BDATA-DATA SIZE = -------- --------
    HUGE-DATA SIZE = 672 --------
    BIT SIZE = -------- --------
    INIT'L SIZE = 6 --------

    This command line produces the code sizes as shown in the listing below:

    c:\keil\c166\bin\c166 "c:\dev\c167\lx100_m_2_3_9\CFiles\Ad.c" HLARGE INCDIR(c:\dev\c167\lx100_m_2_3_9\HFiles;c:\keil\c166\inc) DEBUG CODE PRINT(c:\dev\c167\lx100_m_2_3_9\LFiles\Ad.lst) OBJECT(c:\dev\c167\lx100_m_2_3_9\OFiles\Ad.obj)

    CODE SIZE = 2002 --------
    NEAR-CONST SIZE = -------- --------
    FAR-CONST SIZE = -------- --------
    HUGE-CONST SIZE = 73 --------
    XHUGE-CONST SIZE = -------- --------
    NEAR-DATA SIZE = 10 --------
    FAR-DATA SIZE = -------- --------
    XHUGE-DATA SIZE = -------- --------
    IDATA-DATA SIZE = -------- --------
    SDATA-DATA SIZE = -------- --------
    BDATA-DATA SIZE = -------- --------
    HUGE-DATA SIZE = 672 --------
    BIT SIZE = -------- --------
    INIT'L SIZE = 6 --------

  • 0 in reply to Doug Moore

    Well, after some inspection and talking to someone else, it occurs to me that some of the modules use the __FILE__ predefined macro, so the whole path is probably being stored in the const section in one case, and the relative path in the other case. Doh.

  • 0 in reply to Doug Moore

    and, if you also use the __LINE__ predefined macro, you will find that making changes to just your comments can affect the generated executable for exactly the same reason...!