HAC-based builder for HAC, GNAT and others

[OCTAGRAM]

Hello!

AE2023 slides had an empty space for applications.

I want to propose the purpose. I do not do much prototyping, but I struggle with compilation. I am switching slowly to AdaMagic, and I miss gprbuild here. libgpr depends on latest Ada features. I would like to restrict to Ada 95 until Ada 2005 to C translator appears. Am I right to assume that hac is Ada 95 compatible and will be?

If so, I would like some tool for building in a GNAT & non-GNAT environments. You seem to develop in ObjectAda, and I use AdaMagic. I think about something like Rakefile, but without Ruby. Or maybe gpr can be supported to some extent. gpr is very limited, your hac is mightier, I guess. gpr can be edited by IDE in a high level UI, but if IDE tries to work with my cases and ifs, it becomes not usable, so I do not let IDE edit my project files anyway.

And HAC needs some project handling too. So maybe make HAC-based builder a default for HAC?

I expect ability to output gpr files for gprbuild, VSCode and GPS. And programmable ability to generate projects for other compilers. AdaMagic is using unit map and lib files. I would like to have something like gnatls tool and gnatls object in memory, available for HAC script, to generate project file in a way that particular compiler understands.

I like GPR's way of isolation of projects. I like Mixed_Case.Naming.Like.In.Delphi.ads or like .NET assemblies are named. GPR lets my naming stay separated from other developers' preferences in their projects. I want the same outside GPR.

[zertovitch]

So, you suggest a tool (say "hacbuild") supporting the GNAT project format (to begin with, part of its syntax), so the same .gpr file would work with both hacbuild and gprbuild ? And with some option you could choose which Ada toolchain is used when doing hacbuild -P project.gpr ? Sounds a very good idea. In practice I would make this functionality available from the hac command, so, hac -P project.gpr or even hac project.gpr (after implementing some syntax detection) would be possible.

[OCTAGRAM]

I suggest an opportunity to replace gpr with hac module. With an opportunity to output gpr as one possible option.

There is a chicken-and-egg problem here. We want to replace gpr with hac module, but this hac module itself wants to with our hac modules, and they have to be looked up in some preexisting environment. This preexisting environment shall be created by some hac module that also wants preexisting environment.

GPR has plain GPR_PROJECT_PATH_FILE, GPR_PROJECT_PATH, ADA_PROJECT_PATH lists and aggregate projects for harder cases. Optional with is a harder case in GNAT.

For hac projects we may want some nesting. And some means to avoid nesting. gpr's with is a strong thing. For instance, if I do "with Win32Ada;" in gpr, then I can read Win32Ada project's constants and settings, but I usually don't want to. If I do "with Win32Ada;" in gpr, I often mean "just make your Ada sources available to my project". In hacmake I would like to have built-in procedure instead of Ada's with, but Ada's with also available, for what is really needed for building.

I think about in-memory Project_Collection type that can be eventually output to a directory with gpr. Also, there should be module lookups by Project_Collection type. It should be possible to query "where is GNATCOLL.JSON module?", and this way hac itself can find module.

I think that it all should bootstrap with conversion of ADA_PROJECT_PATH into hacmake's Project_Collection, and each top hacmake module is to be loaded in this context. Then each hac module, being queried to return source Project_Collection, can craft another extended build Project_Collection and invoke function in this altered context. This way we can have auxiliary building modules not popping up directly in ADA_PROJECT_PATH.

[zertovitch]

Regarding the missing ability in the .gpr to import the source paths only, I could not agree more. See for instance the LEA project: I have to maintain two project files, one with withs (this is for the Alire system), and one for the practical development. Back to your suggestion: your vision is project files that are themselves in Ada, right?

[OCTAGRAM]

Yes, like Rakefiles in Ruby in Hakefiles in Haskell and many others. Ordinary programming language with library for essential actions. The notable difference is that for GPS and other projects compatibility it makes sense not to build everything from start to finish, but extract GPR at some point. Like CMake does. CMake can both configure and then generate C++ project for a variety of IDEs. Though it makes trickier assigning post-actions like binary signing.

Or may be not? Maybe it is as simple as replacing standard gprbuild with something that makes full build from the original Ada-syntax project.

Importing and interpreting gpr would be a nice feature, but libgpr is not in Ada 95 ecosystem yet. gpr is superior that it is not Turing-complete, and if something can be done non-Turing complete, that is a better design. But this goal can be failed, and then Turing-completeness should be provided to fill the holes. I am in the failure mindset.