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
