Add ability to generate lazarus package file.

[andrewd207]

I am using lazarus to edit/compile freepascal code. This build system is likely useful/flexible. But to use, for instance, fpgui I have to add one or more paths to the project search path. Not the end of the world, but this is very inflexible. If the project is shared etc, fpgui will likely be in another path.

What if, for libraries an option/flag in the project.xml file could cause a lpk to be generated? The lpk could even have pasbuild run before compilation to recompile the units and/or the lpk. I'm not sure how much lazarus would like that. Compiler Options -> Compiler Commands - Execute Before. Potentially the package could be empty and just adds an -Fu~/.pasbuild/repository/fpgui-framework/{version}/{target}. Not really sure if that's effective.

Alternatively a pasbuild package for lazarus could be made that somehow integrates support for pasbuild projects. A much more difficult solution.

I see that 'install' puts things in ~/.pasbuild. why not ~/.local/[lib,share]/pasbuild. I put pasbuild in ~/.local/bin/ so that I didn't install it globally and it would be in the PATH. This is pretty standarized now.

Also why are projects installing all the unit files? pasbuild install (in the pasbuild project) copies all the ppu/o files but not the binary. Maybe I don't understand fully what it's purpose is.

It's late, my brain is done :)

[andrewd207]

I just tested and this empty package totally works in lazarus. I put it in target/lazpkg/fpgui_framework.lpk

[graemeg]

It was already discussed elsewhere, but for other reading this after the fact, my initial response was here: #7 (comment)

In short, PasBuild 1.7.0 now has plug-in support, so such a feature can easily be added, and can hook into any of the existing build goals. It's document with two example plug-in implementation (bash script & Object Pascal version) here: https://github.com/graemeg/PasBuild/tree/master/extras/plugins/hello-world

To answer your other question about the install command. PasBuild supports internal (same repo) dependencies and external dependencies. The install command is what external dependencies will reference.

For example, lets say you installed the v2.0.3 fpgui-framework.

Any other PasBuild project can then reference that as a dependency, using the following in the project.xml file:

  <dependencies>
    <dependency>
      <name>fpgui-framework</name>
      <version>2.0.3</version>
    </dependency>
  </dependencies>

When you run pasbuild compile in such a project, it will know where to find all compiled units for the fpgui-framework dependency, using the correct version, and FPC target triplet (e.g., x86_64-linux-3.2.2)

On a side note: This is also one of the building blocks for soon to be released online package manager support, where packages can be uploaded by the community, and pasbuild will automatically download and install locally (if they don't already exist locally).

Tip: For Lazarus or MSEide users creating projects that use fpGUI, and where those IDE's don't have native pasbuild support, those developers can simply add a -Fu~/.pasbuild/repository/<some-library>/<some-version>/x86_64-linux-3.2.2/units to the project's Compiler Settings. So they don't need to keep recompiling fpGUI code, but simply use what pasbuild install already compiled and installed.

[andrewd207]

So I've put some idle thought into this in the last days and have some ideas.

• The resolve command simplifies project handling for plugins a lot. Awesome

• I made a change locally so that resolve adds all units detected by bootstrap into the output JSON.

• This feature allows plugins to directly receive the exact set of units pasbuild considers part of the project.

• The output format is a mapping like "UnitName": "/path/to/unitname.pas".

• It could optionally be controlled by a flag such as --units or an env var to avoid doing it by default.

• In what I did before, all *.pas files were included manually, but that caused inconsistency—some files weren’t units recognized by pasbuild.

• The new approach ensures consistency between what units a plugin thinks are part of the project and what pasbuild actually compiles.

"includePaths" : [
    "target",
    "src/main/pascal/corelib",
    "src/main/pascal/corelib/render/software",
    "src/main/pascal/corelib/x11",
    "src/main/pascal/gui"
  ],
  "units" : [
    {
      "agg_2D" : "src/main/pascal/corelib/render/software/agg_2D.pas"
    },
    {
      "agg_alpha_mask_u8" : "src/main/pascal/corelib/render/software/agg_alpha_mask_u8.pas"
    },
    {
      "agg_arc" : "src/main/pascal/corelib/render/software/agg_arc.pas"
    },
  etc ,etc etc

Is that something that fits in pasbuild resolve?

[graemeg]

Hi Andrew,

Thanks so much. It’s always great to see people digging into the project and looking for ways to improve it.

Regarding the points you mentioned about unit discovery and consistency:

I made a change locally so that resolve adds all units detected by bootstrap into the output JSON.

I definitely see where you’re coming from, but I wanted to share the logic behind why it's currently omitted. If you check out the documentation for the 'resolve' command, you’ll see a note at the end of that section:

Note: Individual source file paths are intentionally not listed. PasBuild resolves which directories are active for the current configuration; scanning for specific files is left to the caller...

The core philosophy of PasBuild is to avoid working explicitly with unit lists to keep maintenance low. It’s designed to auto-discover based on conventions rather than maintaining a "source of truth" for files. Adding units to the output—even as an option—creates a contract between PasBuild and plugins that would only ever be approximate, which I worry might lead to more confusion than clarity down the road.

consistency between what units a plugin thinks are part of the project and what pasbuild actually compiles

Just a quick clarification here: PasBuild doesn't actually handle the compilation itself! It tells FPC where to find the units, but it doesn't explicitly list them in the command line. That can be seen in the JSON output too.

I know what you're thinking—the "elephant in the room" is that PasBuild does generate a bootstrap file for library projects that lists found units. 😅 However, that’s really just an implementation detail to work around an FPC limitation. Even in that case, PasBuild doesn't maintain a canonical list; it just globs the directories on the fly. My goal is for plugins to follow that same pattern—deriving the list from the unit paths when needed, rather than relying on PasBuild to store it.

I really appreciate the initiative, though! It's through feedback like this that the project gets better. Let me know if that design choice makes sense from your perspective.

G.

[graemeg]

To explain it with examples. Here is a short list of plugin examples I could think of, and their use case.

Plugin	Files of interest	Why
Lazarus .lpk generator	*.pas	Needs unit names for the package file
Documentation generator	*.pas	Parses comments, interface sections, type declarations
Code formatter	*.pas, *.inc	Formats all source text, including include files
Licence header checker	*.pas, *.inc, *.pp	Verifies every source file carries the correct header
Lazarus .lfm migrator/cleaner	*.lfm	Processes visual form definitions only
Static analyser / linter	*.pas, *.inc	Analyses code for style violations, complexity, dead code
Translation / i18n extractor	*.pas, *.lrt, *.po	Scans for resource strings and localisation files
Line count / metrics	*.pas, *.inc, *.pp	Counts lines, functions, cyclomatic complexity
Dependency graph visualiser	*.pas	Parses uses clauses to build a unit dependency diagram
Resource auditor	*.inc, *.rc, *.res, *.lrs	Checks resource files are present, referenced, and consistent
Dead code detector	*.pas, *.inc	Cross-references declarations against usage across all source
API diff / changelog generator	*.pas	Compares interface sections between versions to detect breaking changes

Every one of these would glob unitPaths (and possibly includePaths) for the file extensions it cares about. No two plugins want the same set. That's precisely why resolve provides the directories and leaves file selection to the caller.