Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
On Tuesday, 9 December 2025 20:00:14 BST Marco van de Voort via fpc-pascal wrote: > > 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. Following up on this comment: the forward planning has already paid off in spades! PasBuild’s convention—a preferred project directory layout—means that if it is followed, the code is logically organised and easy to find, regardless of the language used. In the Blaise compiler project, I have: /rtl/ +- src/main/ +- c/ + C shim code compiled with gcc +- pascal/ + All RTL .pas code here In fpGUI's DocView (help viewer) module, I have: /docview/ +- src/main/ +- ipf/ + .ipf help file source compiled with wipfc +- pascal/ + DocView's application code In both examples, I use a small PasBuild plugin -- local to each project -- that calls out to gcc, qbe, or wipfc to compile the relevant code. It then outputs the results into the `target/` directory, where they can be processed further or packaged into a binary release. The benefits are clear: * No hard-coded paths. * No changes were needed in the project.xml file. * Projects can be quickly cleaned with `pasbuild clean`. * It works on every platform PasBuild runs on. On a side note: PasBuild plugins are language-agnostic and external to PasBuild itself; they can be a .bat file, a *nix shell script, or a compiled binary. They integrate seamlessly in the build pipeline. Regards, Graeme ___ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
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.___ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
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
Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
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? 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? 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. 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. Sorry to be a pain in the *ss, but I do think that spelling the reasons why fpmake is what it is, is important. ___ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
Hi Michael, 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 hit a similar requirement for pasbuild. But my solution ended up being pretty straight forward. For an application project, that's easy, as you only need the program unit to kick off the dependency tree. I let FPC handle that. However, when you compile a framework/library, like fpGUI for example, there is no program unit, and there is no single "starting unit" because of the complex dependencies. In the end, my solution was pretty simple: as I'm scanning the src tree, I track all *.pas,*.pp,*.lpr files and their directories for the FPC -Fu argument. At the same time, I also track *.inc files and the directories they are in, so I can build up the -Fi arguments. PasBuild then simply generates a bootstrap program unit in the 'target' output directory, and I tell FPC to compile that with all the -Fu and -Fi arguments I collected. FPC happily (and luckily) does all the heavy lifting in calculating the dependency tree. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
Hi Marco, First off, thank you for your feedback. ...this does make you wonder why fpmake didn't go for the scanning solution 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! No wonder you hardly see fpmake used anywhere else other than FPC itself. - I should remind that fpmake does not just build single projects, but /hierarchies/ of packages in parallel if possible. Indeed. Parallel compilation is amazing. I'm currently still using a custom shell script to compile all fpGUI's examples in parallel. Compilation takes seconds, versus the serial compilation that took 2-3 minutes. 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. - 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. 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). 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! I hope the convention idea catches on. It works brilliantly in the Java realm, and makes the lives easier for every developer. Fingers-crossed, but I don't expect anything to change overnight in the Pascal realm. One has to start somewhere though. :) 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. - The commandline only, and XML as format seems somewhat weird. I looked at other formats like JSON, YAML etc. XML has stood the test of time, and is very well supported out of the box by FPC. So bootstrapping the PasBuild tool requires no external libraries or tools - just a running FPC. The v1.0 release is my MVP. Minimum features to make it functional and usable. More features like a GUI front-end (fpGUI, Lazarus etc) is nice to haves, but not critical for a 1.0 release. 'pasbuild init' will give you a working project.xml file. If you stick to the conventions, hardly any configuration is needed. Binary files are resources too, and I wouldn't want a pasbuild parser to descent into it. User-configurable include/exclude filtering will be in the next release. It's already on my todo list. 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. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
On Tue, 9 Dec 2025, Marco van de Voort via fpc-pascal wrote: Op 9-12-2025 om 17:28 schreef mailinglists--- via fpc-pascal: I'm excited to announce the first release of PasBuild v1.0.0, a modern build automation tool for Free Pascal projects inspired by Apache Maven! While I over the years I did some work on various FPC related build systems, I wasn't involved in fpm(unit|make)'s specification and requirements. Still some quick thoughts after scanning through the document: - The first is not a pasbuild criticism, but a realisation; reading this does make you wonder why fpmake didn't go for the scanning solution and requires such deep specification. Maybe to package only relevant units, and not target Y specific units when building on X ? I have to admit, I don't know the answer. 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. 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. 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. 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. In summary: it's definitely possible to automate some things more than they are today, but for complex systems, there will anyway be lots of configuration to be done. And if I need to configure, then I prefer to do it in Pascal rather than XML. Michael. ___ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
Op 9-12-2025 om 17:28 schreef mailinglists--- via fpc-pascal: I'm excited to announce the first release of PasBuild v1.0.0, a modern build automation tool for Free Pascal projects inspired by Apache Maven! While I over the years I did some work on various FPC related build systems, I wasn't involved in fpm(unit|make)'s specification and requirements. Still some quick thoughts after scanning through the document: - The first is not a pasbuild criticism, but a realisation; reading this does make you wonder why fpmake didn't go for the scanning solution and requires such deep specification. Maybe to package only relevant units, and not target Y specific units when building on X ? I have to admit, I don't know the answer. - I should remind that fpmake does not just build single projects, but /hierarchies/ of packages in parallel if possible. That is a fpmake killer feature in my view. FPC doesn't compile THAT fast. - I dislike any hardcoded paths, and the chosen defaults (with redundant "Pascal") even more. At the least it should be configurable. If that is possible with a non minimal XML, then fine. I can live with that. Phrases like "Where should I put this file?" sounds hollow it if its my way or the highway. Also makes it hard to retrofit to existing VCS trees. - with any new build tool, if I had any say in it, I would like to strictly separate input files and output files, in totally separate trees like GNU configure does. Having src and target both in one toplevel dir defies that. - The commandline only, and XML as format seems somewhat weird. XML is not a format I associate with manual editing. I'd expect a GUI with that. - Resources as a directory for to be parsed-with-macros files is IMHO a misnomer. Binary files are resources too, and I wouldn't want a pasbuild parser to descent into it. I don't get the testing references, but I currently don't do exhaustive unit testing with a unit test framework, so that might be the reason. ___ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
Hi all,
I'm excited to announce the first release of PasBuild v1.0.0, a
modern build automation tool for Free Pascal projects inspired by
Apache Maven!
GitHub: https://github.com/graemeg/PasBuild
Why PasBuild?
=
While fpmake is powerful, it can be laborious to create and
maintain, especially for large projects. A real-world example:
fpGUI Toolkit has 120+ units, include files in various locations,
and platform-dependent directory trees. The fpmake.pp file was
40KB with over 750 lines of code that needed constant updates when
adding or removing units.
PasBuild's project.xml? Just 3KB and 117 lines - and we know how
verbose XML is. ;-) No updates needed when units change - it
self-discovers your code and dynamically builds the FPC command!
Key Features
Convention Over Configuration
-
- Standard directory layout (src/main/pascal, src/test/pascal)
- Zero configuration for projects following conventions
- Override only what you need to customize
Intelligent Automation
--
- Auto-discovers all units and subdirectories
- Automatic include path detection (*.inc files)
- Self-maintaining - add/remove files without updating config
- Cross-platform path handling (src/main/pascal → src\main\pascal)
Complete Build Lifecycle
-
- clean: Remove build artifacts
- compile: Build your executable or library
- test: Compile and run tests (FPCUnit/FPTest auto-detection)
- package: Create release archives
- source-package: Generate source distributions
Build Profiles
--
- Define multiple build configurations (debug, release, etc.)
- Activate single or multiple profiles: -p base,debug,logging
- Profile-specific compiler options and defines
- Perfect for cross-platform conditional compilation
Resource Management
---
- Automatic resource copying to target directory
- Variable filtering: ${project.version} → 1.0.0
- Supports both main and test resources
- Version injection via resource filtering
Developer-Friendly
--
- Single XML configuration file (project.xml)
- Semantic versioning 2.0.0 with pre-release tags
- Verbose mode for debugging (-v flag)
- Alternate project files support (-f custom.xml)
- Maven-style goal dependencies
Cross-Platform
--
- Works identically on Linux, Windows, macOS, FreeBSD
- Automatic path separator handling
- Platform-specific conditional compilation support
Self-Hosting
- PasBuild builds itself using project.xml
- Demonstrates best practices
- Easy to bootstrap from source
Real-World Testing
==
PasBuild has been extensively tested with:
- Multiple production applications
- fpGUI Toolkit (120+ units, complex structure)
- Projects with platform-dependent code trees
- Libraries and applications alike
Example: Minimal project.xml
=
MyApp
1.0.0
Your Name
BSD-3-Clause
Main.pas
myapp
That's it! PasBuild handles the rest automatically.
Getting Started
===
# Bootstrap compilation
mkdir -p target/units
echo '1.0.0' > target/version.inc
fpc -Mobjfpc -O1 -FEtarget -FUtarget/units -Fitarget \
-Fusrc/main/pascal src/main/pascal/PasBuild.pas
# Now use PasBuild to build itself
./target/pasbuild compile
# Create a new project
mkdir myproject && cd myproject
pasbuild init
Documentation
=
Comprehensive documentation available in the repository:
- Quick Start Guide: docs/quick-start-guide.adoc
- Design Document: docs/design.adoc
- Bootstrap Instructions: BOOTSTRAP.txt
Try It Today!
=
Clone from GitHub:
git clone https://github.com/graemeg/PasBuild.git
Your feedback and contributions are welcome! Please
kindly use the GitHub Issue Tracker.
More features to come soon.
License: BSD-3-Clause
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
___
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
