Avoid the possibility of a zero length generated LD script

[TommyMurphyTM1234]

See here for some background:

• Empty LD file on missing build tools #286
• Compilation results in no code #283

I also experienced this issue when I forgot to add the toolchain to my path and/or used the wrong toolchain PREFIX, tried to build an example, and ended up with a zero length .../ch32v003fun/generated_ch32v003.ld and until this was deleted (or a make clean performed) then the error persisted:

riscv64-unknown-elf-objcopy: error: the input file 'blink.elf' has no sections
make: *** [../../ch32v003fun/ch32v003fun.mk:146: blink.bin] Error 1

To mitigate/avoid this issue, I suggest making the rule for creating the generated LD script .PHONY so that it is always run and thus ensures that the generated linker script is up to date.

.PHONY : $(GENERATED_LD_FILE)
$(GENERATED_LD_FILE) :
	$(PREFIX)-gcc -E -P -x c -DTARGET_MCU=$(TARGET_MCU) -DMCU_PACKAGE=$(MCU_PACKAGE) -DTARGET_MCU_LD=$(TARGET_MCU_LD) $(CH32V003FUN)/ch32v003fun.ld > $(GENERATED_LD_FILE)

I tried other approaches but most seem to require more complexity and dependencies on shell features which may not work on all platforms/shells (especially Windows).

Admittedly this is slight abuse of the .PHONY feature since this is a file based Makefile rule and not something like clean, install etc., and it also means that the LD script will be generated afresh every time a build is done but I believe that the overhead should be minimal and it's arguably a small price to pay to avoid a problem that may confuse users (especially newbies)?

What do others think...?

If there is a more elegant alternative approach then I would be interested in hearing about it.

Thanks.

[cnlohr]

Thank you for finding and solving this. This looks all correct. I really appreciate this work.

[TommyMurphyTM1234]

Thank you for finding and solving this. This looks all correct. I really appreciate this work.

You're welcome. Thanks for accepting and merging the PR. Keep up the good work with this very useful and interesting project. 👍 :-)

[TommyMurphyTM1234]

BTW - this is a slight improvement that still runs the rule every time but only actually (re)creates the generated LD script if it doesn't exist or does but is zero length:

.PHONY : $(GENERATED_LD_FILE)
$(GENERATED_LD_FILE) :
	@if [ ! -f $@ ] || [ ! -s $@ ]; then \
		$(PREFIX)-gcc -E -P -x c -DTARGET_MCU=$(TARGET_MCU) -DMCU_PACKAGE=$(MCU_PACKAGE) -DTARGET_MCU_LD=$(TARGET_MCU_LD) $(CH32V003FUN)/ch32v003fun.ld > $(GENERATED_LD_FILE); \
	fi

However this depends on the shell and on Windows will only work if that is available - e.g. in my case I install the xPack Windows Build Tools:

• https://xpack.github.io/dev-tools/windows-build-tools/

and add it to the PATH which makes these Unix/Linux like tools available (via BusyBox):

dir c:\temp\xpack-windows-build-tools-4.4.1-2\bin
 Volume in drive C has no label.
 Volume Serial Number is 06A0-A88B

 Directory of c:\temp\xpack-windows-build-tools-4.4.1-2\bin

14/11/2023  09:48    <DIR>          .
14/11/2023  09:48    <DIR>          ..
14/11/2023  09:48           623,104 busybox.exe
14/11/2023  09:48           623,104 cp.exe
14/11/2023  09:48           623,104 echo.exe
14/11/2023  09:48           321,024 make.exe
14/11/2023  09:48           623,104 mkdir.exe
14/11/2023  09:48           623,104 rm.exe
14/11/2023  09:48           623,104 sh.exe
               7 File(s)      4,059,648 bytes
               2 Dir(s)  257,208,422,400 bytes free

Obviously other Unix/Linux style command line tools packages such as MSYS2, WSL etc. would work similarly.

But I guess that (re)generating the LD script every time isn't a big enough deal/overhead to necessitate this additional tweak and a dependency on additional external tools on Windows (at least)?