Aurix Build System: application is not updated after modified library

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User22281
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

Dear Aurix Experts,

I am using Aurix Development Studio v1.5.0 to develop an application consisting of a library project and an application project in the same workspace. The application project is linked against the library (project --> properties --> C/C++ Build --> Settings --> Tool Settings --> TASKING Linker --> Libraries).

However, I have noticed that when the library is modified and rebuilt, the ELF file is not updated. Actually, the dependency on the *.a library file is missing in the generated Makefile (the ELF target depends on $(OBJS) only):

# Tool invocations
MyApp.elf: $(OBJS)
	@echo 'Building target: $@'
	@echo 'Invoking: TASKING Linker'
	cctc -lrt -lfp_fpu -lcs_fpu -Wl-Oc -Wl-OL -Wl-Ot -Wl-Ox -Wl-Oy "C:\workspace\MyLib\Debug\MyLib.a" -Wl--map-file="MyApp.map" -Wl-mc -Wl-mf -Wl-mi -Wl-mk -Wl-ml -Wl-mm -Wl-md -Wl-mr -Wl-mu --no-warnings= -Wl--error-limit=42 --exceptions --strict --anachronisms --force-c++ -Ctc36x -o"MyApp.elf" -Wl-o"MyApp.hex:IHEX" --lsl-core=vtc --lsl-file=../Lcf_Tasking_Tricore_Tc.lsl $(OBJS)
	@echo 'Finished building target: $@'
	@echo ' '

In this case, "C:\workspace\MyLib\Debug\MyLib.a" should be added to the dependency list of target MyApp.elf.

Should I modify something in the project properties or is it a bug in the Aurix Build System?

Thank you very much.

0 Likes
1 Solution
enrico_b
Employee
Employee
First like given 10 sign-ins 5 solutions authored

Good morning,

The library is not part of the project, but is an externally created artifact which is not "tracked" by the project linking it. In other words, the lib is considered immutable by the project "MyApp" in ADS, which doesn't support tracking modification of files created externally.

You have two options: you can re-build the project (which will clean it before building), or, if the library project has been created in ADS and resides in the same workspace, you can configure it as a referenced Project in "MyApp" (see screenshot below). This way, ADS will notice modifications in MyLib and trigger a rebuild also for MyApp. If you choose this way you don't need to add the library in the linker options. You can just add the "MyLib" project to the includes of MyApp.

Hope this helps,

Regards.

Enrico

Screenshot 2021-12-17 095645.jpg

View solution in original post

0 Likes
2 Replies
enrico_b
Employee
Employee
First like given 10 sign-ins 5 solutions authored

Good morning,

The library is not part of the project, but is an externally created artifact which is not "tracked" by the project linking it. In other words, the lib is considered immutable by the project "MyApp" in ADS, which doesn't support tracking modification of files created externally.

You have two options: you can re-build the project (which will clean it before building), or, if the library project has been created in ADS and resides in the same workspace, you can configure it as a referenced Project in "MyApp" (see screenshot below). This way, ADS will notice modifications in MyLib and trigger a rebuild also for MyApp. If you choose this way you don't need to add the library in the linker options. You can just add the "MyLib" project to the includes of MyApp.

Hope this helps,

Regards.

Enrico

Screenshot 2021-12-17 095645.jpg

0 Likes
User22281
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

Hello Enrico,

Referencing project "MyLib" from "MyApp" does not help. A rebuild of "MyLib" is indeed triggered, but the executable in "MyApp" is not regenerated because make says "Nothing to be done for 'all'", even if the library has changed. This is because, as I said in my previous post, the generated Makefile does not track the dependency on the library (only on sources from the same "MyApp" project):

MyApp.elf: $(OBJS) <<<___MyLib_should_go_here___>>>>
        ...commands...

The Makefile generated by Eclipse built-in CDT (for CDT managed C/C++ projects) has the same issue.

As a workaround, I have added a pre-build step that deletes the application ELF file, forcing the build system to call the linker to generate a new one. Re-building the whole application is not an option because it takes a significant amount of time (Aurix build process is quite slow compared to other IDEs out there).

0 Likes