[fpc-pascal] Introducing PasBuild 1.0.0 - Maven-Inspired Build Tool for Free Pascal
mailinglists at geldenhuys.co.uk
mailinglists at geldenhuys.co.uk
Tue Dec 9 19:08:47 CET 2025
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/
More information about the fpc-pascal
mailing list