[fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal

[Michael Van Canneyt]

On Tue, 9 Dec 2025, Marco van de Voort via fpc-pascal wrote:

>
> Op 9-12-2025 om 18:54 schreef Michael Van Canneyt via fpc-pascal:
>>
>> Nothing stops you from adding a loop that scans the (sub)directories and
>> adds units as targets. The fpmake from pas2js does that. We could 
>> maybe add
>> a convenience call to automate this.
>
> That's also what I thought. Beside fpmake for the heavy duty side of 
> things (with partial generation or not), and a simple Lazarus group 
> project on the other hand for simple, in order builds, what is the point 
> of pasbuild? I only realised that after my previous post.
>
>> As you noted, fpmake can do parallelism. In order to process 
>> files/packages in the correct order, you need to specify the 
>> dependencies correctly. This requires
>> rigourous analysis of the source files (uses clauses and include 
>> directives)
>> with all the correct defines in place etc.
>
> I don't know, that somehow doesn't make sense to me. Does fpmake really 
> analyse cross package?

It treats packages as monolithic. That is why you need to specify package
dependencies.

Theoretically, fpmake can figure all out all the unit and package
dependencies itself if all packages are created in 1 run 
(as in the toplevel fpmake in packages).

>> When fpmake was written, there simply was no tool that could do this
>> correctly. Today such a tool exists, and we can think about automating 
>> this.
>>
>> Note that if these dependencies are not correct, you run into all 
>> kinds of errors
>> when doing parallel compilation.
>> Pierre will probably paint a more complete picture than I do.
>
> I would be glad to hear about it.  But I thought that Joost wrote the 
> core of fpmake?

I did, with Peter Vreman. Joost added fppkg, which of course builds on
top of fpmake. He did do some important changes to fpmake to make it more 
useful at that time, if memory serves well.

>
> Something there doesn't compute IMHO. Either I'm missing something, or 
> the required detail is more than needed, or for some other purpose than 
> straight build.

The original fpmake didn't know the concept of a build unit. 
If you use a build unit, then the compiler will of course 
figure most things out by itself.

If no build unit is used, fpmake can parallelize compilation 
up to unit level, but then it needs a lot of dependency info. 
(which is what you see in packages).

If a build unit is used then parallel compilation is restricted to the 
package level.

>> fpmake also prepares the installs and zips. You need to know what 
>> files need to be installed and what not. This can be automated to some 
>> degree, but never fully.
>
> That is after a build. Parsing FPC output could give you that information.

You also need the examples etc.

>
> Sorry to be a pain in the *ss, but I do think that spelling the reasons 
> why fpmake is what it is, is important.

I don't think you're being a PITA ? You're right, It is time fpmkunit got 
documented and its usage and purpose explained in more detail.

But I'm working on it, as you'll soon see.

Michael.