C template project - Makefile doesn't see main.c changes

Hi,

I’m developing a program based on torizon extension2 C template.

I remark that the Makefile doesn’t build my main.c everytime even if i did modification into it.

I know that Makefile build only when there is change, but even if i modify or write voluntary an error into it, it doesn’t fail and the Hello Torizon executable run.

I don’t want to use the .PHONY to force because i think there is a real issue behind this.

Did you also note this issue please ?

Thank you!

Greetings @FloSolio,

I don’t believe I’ve observed such a behavior before. Whenever you make a modification to a file are you making sure to save your changes in VSCode? Sometimes I noticed VSCode does not see the latest changes in a file unless you save that file in VSCode. Perhaps this is the issue you’re seeing?

Best Regards,
Jeremias

Hi Jeremias,

I saved the file, but after replacing the makefile from template it is ok.

I also have the problem when i do modification in a .c that is in a subfilder of /src.

I add the filder in makefile with -Isrc/test it build and run but modifications are not seen :frowning:

Build-debug-arm64 task indicates, nothing to be done for ‘debug’.

We can see here that i did an error in the test.c file and VSCode doesn’t have seen the change and doesn’ rebuild the object file.

I also used the clean-arm64 task to remove object files.

But when we call build-debug-arm64, an error happens :

SRC are:  src/main.c test.c
OBJ_DEBUG: build-arm64/debug/main.o build-arm64/debug/test.o
aarch64-linux-gnu-gcc -Iincludes/ -Isrc/test -Isrc/sx1302_hal/libloragw/inc -c -g -o build-arm64/debug/main.o src/main.c
make: *** No rule to make target 'build-arm64/debug/test.o', needed by 'build-arm64/debug/LoraTest1'.  Stop.

i realise that no target are in charge to create the first time the main.o or test.o .

For example , if you remove the main.o from build-arm64/debug , and try to rebuild, it will proceed like this:

execute rule debug → depends on target_debug equivalent to taget name build-arm64/debug that depends on OBJ_DEBUG, which is just build-arm64/debug/main/o .

So as i remove the main.o to make the test of object regeneration, it crash. but it is normal as the compilation step is not executed by no body. The two target that should build that are :

$(OBJ_PATH)/%.o: $(SRC_PATH)/%.c*
@echo “Compiling $<”
$(CC) $(CCOBJFLAGS) -o $@ $<

$(DBG_PATH)/%.o: $(SRC_PATH)/%.c*
@echo “Compiling $<”
$(CC) $(CCOBJFLAGS) $(DBGFLAGS) -o $@ $<

But it seems to never been executed, why ? This i don"t understand.

@jeremias.tx

Is it possible that the date is the root cause of skipping makefile to build the object file ?

Because on my pc it is 7 mars 2024 , 14h13.
and when I connect on my mallow board : 7 mars 2024, 13h13.

So when it push the file it is my pc date and the execution date of the make is older so make skip the build ?

Yeah I’m not seeing the same behavior you’re seeing. If I make a change to one of the source files and I save the change the next compilation will take into account my change.

So when it push the file it is my pc date and the execution date of the make is older so make skip the build ?

I don’t think anything about the process relies on timestamps or anything. But if you try to align the times does it fix your issue here?

Also what kind of system are you running VSCode on?

Does this only happen with the makefile project? Or do you see other templates also not noticing your changes?

Best Regards,
Jeremias

Actually, I restart from a blank prohect and it works again…

Can you remove the main.o and try to build again ?

Are you able to re create the main.o ?

I have another issue after being able to build a library and use the static library in my main.c.

It is the docker pull that generate error 18.
It mentionned that i should run docker compose build myApp-debug first, what is alrezdy done in the task order when you click run and debug

It isnnot the first time I get this problem too.

I’m running vscode on ubuntu machine (after failing with vm because of too much port complexity)

Actually, I restart from a blank prohect and it works again…

Well that’s good to hear, not sure what was wrong with your project previously.

Can you remove the main.o and try to build again ?
Are you able to re create the main.o ?

If I do the debug process. Then stop and delete build-arm/debug/main.o, then do the debug process again I can see that main.o gets re-created.

I have another issue after being able to build a library and use the static library in my main.c.
It is the docker pull that generate error 18.
It mentionned that i should run docker compose build myApp-debug first, what is alrezdy done in the task order when you click run and debug

Could you clarify this? This is a separate new issue now right?

Can you please describe exactly what you’re doing here and include the relevant logs for this new issue. From your description here it’s not clear to me what exactly you’re doing and what is going wrong.

Best Regards,
Jeremias

So my project is a Lora gateway (sx1302 chip) connected to AM62 Mallow board.

I checkout the library sx1302_hal written in C.

Goal is to build this library for am62 target and use the Lora function to scan and collect data from local lora water metering equipment.

First, my starting point was to create a new container project based on vscode extension2 torizon C template.

The sx1302_hal folder is placed into src/ folder.

I modified the makefile to first, build the sx1302_hal archive (sx1302 makefile target) , and then run the 'toradex ’ origin debug target. By doing that, i’m sure to have the libxxx.a with all the code i will use in my main.c ( or additional .c files) cross compiled for my target arm64 am62 board.
image

sx1302_hal:
$(MAKE) all -e -C src/sx1302_hal

.PHONY: debug
debug: sx1302_hal $(TARGET_DEBUG)

To use the library, i add -l and -L options to the LDFLAGS:

CC := gcc
CCFLAGS := -Iincludes/ -Isrc/sx1302_hal/libloragw/inc
DBGFLAGS := -g
LDFLAGS := -Lsrc/sx1302_hal/libloragw/ -Lsrc/sx1302_hal/libtools -lloragw -lm -lparson -lbase64 -ltinymt32 #-lm is for math.h (to avoid compile errors :pow , log10 functions calls)
CCOBJFLAGS := $(CCFLAGS) -c
ARCH :=

  • Issues I met were:
    ->Pb1 : sometimes modifications done in src files were not taken into account by the makefile, so object files were not regenerated.
    ->Pb2 : If i removed the main.o, not regerated and then ask for it in compilation errors (make).
    ->Pb3: Container pull step were giving error 18 on my stationnary pc.

Pb1: fixed when create a new project
Pb2: fixed by replacing makefile
Pb3: fixed by moving from my home network to the work pc and work network

So to conclude, to day all is working.
I think that playing and experimenting with makefile, VS an extension at same times created some stange situations.

Now, i’m able to call a function of the sx1302 library ( just get_version(), not yet real communication with the hardware), but it is a good start.

I’m learning by doing so i feel sorry to create tickets sometimes for that, but the toradex way of working is closer to devOps than microcontroler engineer like me :smiley: , so i just need time to improve my skills.

So next step will be to create a dts file to connect my sx1302 gateway to the mallow board and prey that it works :slight_smile: .

Thanks for your time Jeremias.

See you in the next tickets :beers:

1 Like

I’m glad to hear you were able to get everything sorted out here!