Hello,

Just letting you know that some recent changes seem to have broken "make distclean" for source/utils

Makefile.fpc in the source/utils folder contains the line:

CLEAN_TARGET_DIRS=$(subst /Makefile.fpc, ,$(wildcard */Makefile.fpc))

But a recent commit (25 July 2023) removed all the Makefile.fpc files from source/utils/* so it now finds no targets to clean.

I tried changing the line to :

CLEAN_TARGET_DIRS=$(subst /Makefile, ,$(wildcard */Makefile))

which is the same as what is used for source/packages but then it fails because the Makefile in the sim_pasc folder doesn't have a distclean target.

For now I've resolved by adding the list of target folders directly to CLEAN_TARGET_DIRS but hopefully you have a better solution.

Thanks,

Garry.

16.08.2023 4:29, Garry Wood via fpc-devel пишет:

Hello, Just letting you know that some recent changes seem to have broken “make distclean” for source/utils

Please create a bug report.

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 ?

Michael.

Michael Van Canneyt wrote

[...]

After doing "make disctlean" I still have many ppu files left:

./compiler/x86_64/units/x86_64-linux/cutils.ppu
...
./compiler/x86_64/lazbuild/nobj.ppu
...
./rtl/units/x86_64-linux/cp8859_1.ppu
...
./utils/pas2js/lib/x86_64-linux/pas2jsjsresources.ppu

That's why I get on "make all OPT='-gw2'":

make[5]: Entering directory '/home/mattias/pascal/fpc/3.3.1/compiler' /usr/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/home/mattias/pascal/fpc/3.3.1/rtl/units/x86_64-linux -Fix86_64 -FEx86_64/bin/x86_64-linux -FUx86_64/units/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/11 -dRELEASE -gw2 -dx86_64 -dGDB -Fux86 -Fix86 -o/home/mattias/pascal/fpc/3.3.1/compiler/ppc1 pp.pas PPU Loading /home/mattias/pascal/fpc/3.3.1/rtl/units/x86_64-linux/system.ppu PPU Invalid Version 208
Fatal: Can't find unit system used by pp

Mattias

Where do you do this "make all" ?

1. The error is that it cannot find the system unit. To my knowledge, that cannot be caused by stray leftover units.

2. At the top level, You must call "make all " with a release compiler. I do not see you specifying this option.

Michael.

Compiler and RTL are not using fpmake, so this must be something else.

Michael.

Michael Van Canneyt wrote

[....] Where do you do this "make all" ?

top level

Because that is already the default compiler.

$ fpc -v
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64

Mattias

It seems I accidentally compiled with sudo. It would be nice if the clean up would stop if it can't delete a file.

Mattias

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.