[fpc-devel] Recent changes break distclean for utils

[Garry Wood]

>On Fri, 18 Aug 2023, Michael Van Canneyt via fpc-devel wrote:

>And that is how it is supposed to be. 
>The distclean is only needed at the toplevel. The rest is handled by fpmake.
>So there is no need to call distclean for subdirectories, this means that CLEAN_TARGET_DIRS must be empty.

>So what is the actual problem ?

The problem is when we do:

make distclean

and then:

make OS_TARGET=win32 CPU_TARGET=i386 all

Everything in the folders under source\utils (like fpcmake, fpcmkcfg etc) doesn't get built because the units and binaries are not being cleaned from the source.


BUT your mention of fpmake reminded me that we have a line at the top of all of our build scripts that deletes any copies of fpmake.exe from the source folders before starting a build.

This was done because the build always failed with the message "Something wrong with fpmake exectable. Remove the executable and call make recursively to recover.".

Since the recent changes to the makefiles that means because source/utils/fpmake.exe has been deleted then the clean doesn't occur (because it now relies on fpmake).


If we don't remove fpmake.exe first we still get that error but looking closer at the Makefile in source/utils I see that the error should only be output if inUnix is defined which it shouldn't be on Windows.

It turns out the test near the start of the Makefile which checks for:

ifeq ($(findstring ;,$(PATH)),)

was incorrectly detecting Window as Unix because the path we set in the script (one single path to the FPC binaries) didn't have a ; on the end, because it isn't required.


So that resolves a long standing issue with our build scripts, personally I'd say the test for a ; in the path is an unreliable way to check for Unix versus Windows but now we know about it we'll make sure we don't do that anywhere again.

Cheers,

Garry.