Lazarus & FPC Makefiles are "broken"

[Warfley]

Yes I know the makefiles work, but let me explain:

I recently build some different versions of Lazarus, and impatient as I am, I wanted to speed things up by using makes parallel build feature:

Code: Bash  [Select][+][-]

1. make -j20 bigide

Which resulted in the following error:

Code: Pascal  [Select][+][-]

1. /Developer/lazarus/components/lazutils/lazutils.pas(26,3) Fatal: (10022) Can't find unit LazarusPackageIntf used by LazUtils

Meaning the dependencies make uses are not correctly set up. So I looked into the makefile and found the reason:

Code: Bash  [Select][+][-]

1. all: lazbuild lcl basecomponents ide starter

Lazarus depends on the lcl and on basecompontents, which, I think, also depend on the lcl. So the dependencies should be modelled with

Code: Bash  [Select][+][-]

1. all: lazbuild starter
2. starter: ide
3. ide: lcl basecomponents
4. basecomponents: lcl

Also the following:

Code: Bash  [Select][+][-]

1.  basecomponents:
2.    $(MAKE) -C components/buildintf
3.    $(MAKE) -C components/debuggerintf
4.    $(MAKE) -C components/lazcontrols
5.    $(MAKE) -C components/ideintf
6.    $(MAKE) -C components/synedit
7.    $(MAKE) -C components/lazdebuggergdbmi

can be solved with makes dependency mechanics (basically creating a goal for each component and having them have requirements)

In general, this makefile looks more like a bash script than anything else, and as a make file this is broken, because it does not correctly model dependencies (a cornerstone of how make works).

The makefiles are generated by fpcmake, so the question arises, does fpcmake generate this make code or are there even technical limitations to this (like fpcmake can't model dependencies like make can) or is possible but just not modelled in the fpcmake input data?

No matter what, these makefiles are pretty broken, because make files should not rely on the order in which their dependencies are listed (because make ignores this order if other constraints exist, or it is used for parallel building).

Building fpc and lazarus together takes rather long (~ 20 minutes) and I just came to the point where I had to build a docker image, experimenting with build options and having to rebuild over and over again. It gets really annoying to wait 20 minutes just to see what effect a single change had

So my final question is, are there any intentions to "fix" the buildsystem, or is the current state just "good enough" and I have to suck it up?

[DonAlfredo]

As maintainer of fpcupdeluxe, I have encountered many issues with the FPC and Lazarus Makefiles.
So yes, they are not perfect.
But best practice is to make your own changes, test them, and finally file a bugger with your proposed (and tested) changes.

Sidenote:
Using jobs when building Lazarus or FPC cross-compilers might be a no-go !

[Jonas Maebe]

The FPC makefiles should work fine with -j x, as long as you don't try to do a "make clean all" in one go (use separate commands for that). To further speed up building FPC, also add FPMAKEOPT="-T x".

[PascalDragon]

The makefiles are generated by fpcmake, so the question arises, does fpcmake generate this make code or are there even technical limitations to this (like fpcmake can't model dependencies like make can) or is possible but just not modelled in the fpcmake input data?

Looks like these rules are contained in the Makefile.fpc rather verbatim, so this should definitely be fixable. You can try that yourself by adjusting the Makefile.fpc (which is located right next to the Makefile) and then run fpcmake -Tall Makefile.fpc. If your changes work correctly file a bug with a patch and everyone will benefit.

Sidenote: it's likely that the Makefile comes from a time when parallel compilation wasn't that common and nobody bothered to update it since most recompilations are done from within the IDE which is capable of compiling packages in parallel.

[marcov]

Note that FPC makefiles only parallelizes whole directories (e.g. package or component dirs), and not files. This might prohibit it from reaching high levels of parallelism.