Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12600 Discussions

Make dependencies not working for EDS with Quartus Prime Version 20.1.1 Standard Edition

MViss4
Novice
1,107 Views

When building a new Nios II application the make dependencies are not working correct. This means that when changing a header file not all related .c files are compiled. Causing incorrect software!

I have attached an example project which demonstrates this:

  1. main.c calls a printf:
    printf("Hello World %d\n",TEST2);
    Thus main.c depends on test2.h for the macro TEST2
  2. main.c calls function myfunc()  which is implemented in test2.c and calls a printf: 
    printf("Hello World %d\n",TEST2);
    Thus test2.c is also depending on test2.h for the macro TEST2
  3. When changing the value of macro TEST2 in test2.h and saving the file and hereafter building the project does NOT recompile main.c and test2.c! 

Thus the Make dependecies are not handled correctly and when examining the obj/main.d and obj/test2.d dependency files it can be seen that both files depend on test2.h!

Some how in the make process the dependecy files are not correct generated or interpreted
Causing incorect code which can only be corrected by doing a clean an full rebuild!

Environment used:

  • Quartus Prime Version 20.1.1 Build 720 11/11/2020 SJ Standard Edition
  • WSL 1 - Ubuntu 18.04 LTS - GNU Make 4.1 Built for x86_64-pc-linux-gnu
  • Windows 10 version 1903 (OS Build 18362.1256)
  • Eclipse Version: Mars.2 Release (4.5.2) Build id: 20160218-0600
0 Kudos
4 Replies
BoonBengT_Intel
Moderator
992 Views

Hi @MViss4,

 

Thank you for posting in Intel community forum, hope this message find you well and apologies for the delayed in response.
While trying to understand the situation, when there is an updates in the BSP files (i.e. test2.h) the nios ii apps project is not updates I assume, for that case I would suggest to rebuild (right click -> index -> rebuild) the apps project to see if that works.
If that does not help, maybe rebuilding the BSP with the following steps here.
Please do let us know if that helps.

 

Best Wishes
BB

0 Kudos
BoonBengT_Intel
Moderator
981 Views

Hi @MViss4,

 

Greetings, unfortunately as we do not receive any further clarification on what is provided. Hence this thread will now be transitioned to community support. If you have new queries or further query on this thread, please feel free to open a new thread or reopen this thread to get support from us. Otherwise, the community users will further help you with doubts in this thread.

 

Best Wishes
BB

0 Kudos
MViss4
Novice
974 Views

Please note I have made case 00604188 in https://premiersupport.intel.com/ for this and it was confirmed that dependencies are not working.
And a fix is scheduled for the next release of Quartus.

Just for reference recently a colleague of mine has found a workaround as a rebuild is not really a sollution when you have to wait untill newlib is build which takes ~15min each time (with no build feedback!)

 Fix incremental build (ctrl-b) when header file is updated

When a header file is updated the incremental build (ctrl-b) does not rebuild the objects that depend on the header file. So currently a clean + rebuild is needed.

This can be fixed with the following changes in the Makefile:

  • In the Makefile for the project search for "-include $(APP_DEPS)" and adapt this to: 

    # Fix to always include Application dependency files
    # Include the dependency files unless the make goal is performing a clean
    # of the application.
    #ifeq ($(firstword $(MAKECMDGOALS)),)
    #ifeq ($(firstword $(MAKECMDGOALS)),app)
    -include $(APP_DEPS)
    #endif
    #endif

 

  • In the Makefile for the project search for "define compile.c" and adapt this to: 

    define compile.c
    @$(ECHO) Info: Compiling $< to $@@
    @$(MKDIR) $(@D)
    $(CC) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
    @# Fix to correct paths in .d files
    @dos2unix -q $(@:.o=.d)
    @sed -e 's@[cC]:@/mnt/c@' -e 's@[dD]:@/mnt/d@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
    $(CC_POST_PROCESS)
    endef

 

  • In the Makefile for the project search for "define compile.cpp" and adapt this to:

    define compile.cpp
    @$(ECHO) Info: Compiling $< to $@@
    @$(MKDIR) $(@D)
    $(CXX) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CXXFLAGS) $(APP_CFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
    @# Fix to correct paths in .d files
    @dos2unix -q $(@:.o=.d)
    @sed -e 's@[cC]:@/mnt/c@' -e 's@[dD]:@/mnt/d@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
    $(CXX_POST_PROCESS)
    endef

 

  • In the Makefile for the project search for "define compile.cpp" and adapt this to:

    define compile.s
    @$(ECHO) Info: Assembling $< to $@@
    @$(MKDIR) $(@D)
    $(AS) -MP -MMD -c $(APP_CPPFLAGS) $(APP_CFLAGS) $(APP_ASFLAGS) -o $@ $< || (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)
    @# Fix to correct paths in .d files
    @dos2unix -q $(@:.o=.d)
    @sed -e 's@[cC]:@/mnt/c@' -e 's@[dD]:@/mnt/d@' -e 's@\\@\/@g' -e 's@\/$$@\\@' -i $(@:.o=.d)
    $(AS_POST_PROCESS)
    endef

 

The -include $(APP_DEPS) command is never included due to the nested (wrong?) ifeq statements

"|| (ret=$$?; rm -f $@ $(@:.o=.d) && exit $$ret)" removes .o and .d file if gcc compiler returns with an error

The sed command converts the windows paths in the .d file to WSL path notation (e.g. C:\path\to\file is replaced by /mnt/c/path/to/file)

Warning: the sed command currently only supports C and D drives.

0 Kudos
dscully
Novice
626 Views

Unfortunately, I can confirm this issue still occurs on the recently released Quartus Pro 22.4 so it looks like they still haven't fixed the incorrect Application Makefile generation.

0 Kudos
Reply