Ideas: more conditional flags, version logic, profile stuf more :)

[andrewd207]

😁 I think this is a great tool so I'm writing all this. It's meant to be constructive.

1. condition attribute on <dependency> and <moduleDependency>. Unit paths already support condition, so deps are the obvious gap. Example: I have a cross-platform audio suite whose pulseaudio dependency makes no sense on Windows. Being able to write condition="!windows" on that dependency would solve it cleanly. Negation matters here — "everywhere except" beats enumerating every platform and forgetting a future one. Maybe excude="windows arm" ?

2. Version ranges. Allow >= so a project can accept "this release or newer." The dev-vs-release case is just semver pre-release precedence: a strict 1.2.0 shouldn't match 1.2.0-dev, but >=1.2.0-dev should. If ranges land, a lockfile pinning resolved versions keeps builds reproducible.

3. Compiler-aware profiles. A compiler="fpc" / compiler="blaise" attribute on <profile> (and ideally on individual options) would let a project support both compilers with different defaults, and let pasbuild warn when a profile is used with the wrong compiler. A project-level declaration of the supported/default compiler would help too. The compilerOptions tag itself could have a compiler tag. if there are two compilerOptions tags with an attribute defined for each compiler that would allow setting defaul options for each.

4. Friendlier compiler mismatch error. Right now pasbuild compile on the Blaise project reports an internal error when it falls back to fpc. A check up front — "this project targets blaise; pass --compiler blaise" — or defaulting to the declared compiler would be much nicer than a crash mid-build.

On condition semantics something like an include/exclude list, not a boolean expression. Space-separated tokens; a positive token means "match any of these," a !-prefixed token means "exclude." So condition="!windows linux bsd" means linux or bsd, never windows. No OR keyword, no parentheses, no nesting. If a project needs something more elaborate than that, it can split into separate entries.

And not that it's common, but your project structure allows for /src/main/pascal or /src/main/c or anything you want. so there could be compiler options there for $X.

Something that keeps biting me. Calling pasbuild within a module directory keeps failing because there is no version attribute. It would be nice if it looked for a parent module to get the version. Either checking if it's a git repo and looking in the root or just traversing a level or two back in the path for a parent.

If a project has declared it's own plugins it would be nice to be able to add a plugin that needs to be called before the compile step. My pb-editor project has some ascidoc help files that get compiled into a .res file before compilation. If compilation depended on a "pasbuild-buildhelp" plugin (in the project dir) that could just happen automatically. I was using fpc trunk but 3.2.2 doesn't support -FF to automatically compile resources.