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

[Marco van de Voort]

Op 9-12-2025 om 19:08 schreef mailinglists--- via fpc-pascal:
>
> First off, thank you for your feedback.

No problem. The Pascal (with units/module) buildsystem is unique, and it 
has many really strong points.  However it is essentially a vision of 
Wirth from 1978-1980, and reinterpreting it for an 8 cores under $100 
world will be challenge and require some major thinking.

Some discussion about it will certainly help.

In the long term, I don't think we can escape a multithreaded compiler 
that is fed with some previous compile run's output, to quickly acquire 
a tentative unit dependency chart, to find suitable candidates to fire 
up the compilation of multiple units at once.Or maybe hints in the build 
unit USES clause what are the roots (though I like the live feedback 
more, but the trouble is that that is often target dependent)

>  That would be interesting to know. I've literally spent hours editing
> fpGUI's fpmake.pp and it's still not doing what I want, and it's
> massive! 

See my reply to Michael. While his answers didn't  fully satisfy me, I 
do wonder why you opted for YAB. (Yet Another Buildsystem) rather than 
opt for a  fpmake generator to directly fix your grievances by 
automating the fpmake tedium for straightforward packages. E.g. a 
fpmake.pp with a big {$I some.inc}  where the dependencies are, and a 
"some.inc" generator.....

That is the other thing with Java. Comes with the corporate focus I 
assume, all noses in the same direction, no forking into oblivion on 
mere ideas.

> No wonder you hardly see fpmake used anywhere else other
> than FPC itself.

Well. For simple in order compilation, Lazarus project groups are 
enough.  pasbuild will have to fend off competition both from the high 
end (fpmake) and the low end (laz group project, as just good enough and 
compiles multiple projects.....)

>  So multi-module support (projects inside a project) and parallel
> compilation is coming very soon. After seeing the speed difference,
> it's a must for me too. It just wasn't part of the MVP (minimum
> viable product) feature list for v1.0.

MVP IMHO implies having at least one clear edge, even if just slight. I 
fail to see that for pasbuild ATM. At least for me, from the perspective 
of a Lazarus user, it doesn't really fix any problems that I have atm. 
While I mostly use lazarus for utilities and still Delphi for the big 
code bases, my usage of Delphi is not unlike Lazarus, so that still counts.

>> - I dislike any hardcoded paths, and the chosen defaults (with
>> redundant "Pascal") even more. At the least it should be
>> configurable.
>
> Both the input and output paths are configurable.
Good, keep in mind the other remark of the separate output and input trees.
>
> After working a few year with Java now, I've quickly realised that I
> can clone pretty much any Java project and from the command line,
> run 'mvn verify' and it builds the project and runs the test suite
> (optional).

For me, going to the command line for the trivial case is stepping a few 
decades back in time. As is manual XML editing.

And as said, Delphi/FPC projects had that for a long time by running 
lpis/dprojs/dpk/lpk etc. Yes, there are still problems there (parallel 
build, Delphi has problems with requiring absolute paths, Lazarus 
improves, but often still requires to manually open lpks to force 
recompiles rather than do it automated)

> Returning to Pascal recently, I quickly realised what a mess the
> ecosystem is. No standards, each project does it's own thing. It makes
> it really hard for anyone to use. My fpGUI project is no exception!
> Currently my fpGUI documentation lists 4 different ways in how you can
> compile and use the project. That's just crazy!

Usually you just compile the .lpi or lpk.  Recursively getting 
dependencies from the internet is possible, but a can of worms, as many 
javascript and python repository vulnerabilities have proven.

Those repos relaxed checks and bounds to grow fast, but it came at a 
price....

> As for the 'pascal' in the path. I have plans for future expansion,
> like a src/main/asciidoc or src/main/ipf etc directories. In the
> future, PasBuild could compile application or framework help files, or
> the project website, side-by-side with the source code.

I'm a bit wary of everything but the kitchen sink kind of tools. Usually 
they excel in neither aspect very well.

>
> 'pasbuild init' will give you a working project.xml file. If you stick
> to the conventions, hardly any configuration is needed.

At the very least there should be a global configuration file to hash 
out your own conventions rather than enforce an arbitrary convention set 
by others.

>>  I don't get the testing references, but I currently don't do
>> exhaustive unit testing
>
> For me, a test suite is a must. But again, it's optional for PasBuild.
> Even if you don't have a src/test/ directory tree and run
> 'pasbuild test', it will happily compile your standard source code,
> but skip the test phase.

It depends on the job. If I were in my previous job, I would probably be 
worrying about test coverage of the business code.

In my current job, not really. I have tests for some crucial/complex 
bits that I run manually when I work on those.  The rest is make it up 
as you go/ it what it is. There is no "right" or "wrong" ex ante, all 
requirements and specs are fluid. The fact that the input arrives as an 
10 GBit/s image stream doesn't help either. The number of hypothetical 
cases is just too big to even enumerate, let alone test.

Even if you somehow manage to wrestle "the right"  at great expense from 
the scant requirements, it might be subverted the moment it goes live by 
a simple remark of a customer like "it rejects really a lot, even though 
it is on spec. We can't make a profit that way. Dial it down a bit ".

The life of a machine vision programmer is a continuous grey  area :-)