New tool "gprexec", basically "make with project file"

New tool "gprexec", basically "make with project file"

[VM Celier]

I am starting a new project that I have been thinking for several years: gprexec.

gprexec is a "Make build automation tool using GPR project files to describe goals, dependencies, and processes".

It uses a new package: Execution.

Here is an example of a project that can be used by gprexec:

project Toto is

   for Main use ("toto.adb");

   package Execution is
      for Process ("display_main") use ("cat", "toto.adb");
      for Dependency ("display") use ("display_main");
      for Process ("display") use ("cat", "toto.gpr");
      for Process ("date") use ("date");
      for Process ("toto") use ("gprbuild", "-f", "-q", "toto.gpr");
      for Dependency ("default") use ("display", "toto", "date");
      for Process ("default") use ("toto");
   end Execution;
end Toto;

Package Execution has these attributes:

- Dependency, to indicate the goals that need to be processed before
  the indexed goal.


- Process, to indicate the process to be invoked, with its arguments,
  for the indexed goal.

gprexec needs to be invoked with a single project file and an optional goal. When no goal is specified on the command line, the goal "default" is implied.

For example with the project file toto.gpr above, invoking

   gprexec toto.gpr

the goal default will be used, and according to the dependencies processes will be invoked in the following order:

(goal "display_main): cat toto.adb
(goal "display"):     cat toto.gpr
(goal "toto"):        gprbuild -f -q toto.gpr
(goal "date"):        date
(goal "default"):     toto

After displaying the main toto.adb and the project file toto.gpr, toto.adb is compiled, bound and linked, the date is displayed and the executable "toto" is invoked.

gprexec uses the project file "gpr.gpr", part of the gprbuild repository.

I just created a public repository for gprexec on Github:

   https://github.com/vmcelier/gprexec

Anybody interested?

--  Vincent Celier
(no longer associated with AdaCore)

Re: New tool "gprexec", basically "make with project file"

[Shark8]

On Friday, January 11, 2019 at 3:00:12 PM UTC-7, VM Celier wrote:
> 
> Anybody interested?
> 

Yes, but no.
Some of the ideas behind GPR are good, but if we're being honest its tendency to be "stringly-typed" is annoying given its obvious designed similarity to Ada -- and there are a lot of missed opportunities -- and the sort-of configuration purposes which don't fully support producing an Ada executable. (eg IIRC you have to use a completely separate configuration to handle DSA.)

Re: New tool "gprexec", basically "make with project file"

[VM Celier]

> Some of the ideas behind GPR are good, but if we're being honest its tendency to be "stringly-typed" is annoying given its obvious designed similarity to Ada

It is true that the syntax of the project language is similar to the one of Ada, but there is a big difference between the two languages:

- Ada is an executable language
- the project language is a declarative language

You don't "execute" project files, you use it to describe a system for different tools. This is why there are almost no types in the project language because types are not really needed and they would complexify the language for no real benefit.

> -- and there are a lot of missed opportunities

Could you tell us one or two of these missed opportunities?

--  Vincent

Re: New tool "gprexec", basically "make with project file"

[Shark8]

On Monday, January 14, 2019 at 5:49:16 PM UTC-7, VM Celier wrote:
> > Some of the ideas behind GPR are good, but if we're being honest its tendency to be "stringly-typed" is annoying given its obvious designed similarity to Ada
> 
> It is true that the syntax of the project language is similar to the one of Ada, but there is a big difference between the two languages:
> 
> - Ada is an executable language
> - the project language is a declarative language

This is actually less of an issue than might be thought; though some of the "fix-ups" might be a bit stifling to some. You could, for example, impose restrictions/mandatory-structure on the configuration and have all configurations be valid Ada.

> 
> You don't "execute" project files, you use it to describe a system for different tools. This is why there are almost no types in the project language because types are not really needed and they would complexify the language for no real benefit.

No, real enumerations (and attendant Ada-like case-coverage) would be excellent for providing bounded alternations of the configuration.

> 
> > -- and there are a lot of missed opportunities
> 
> Could you tell us one or two of these missed opportunities?

Given Ada's strong generic-system configurations could be described as generic parameters [esp enumerations], which the tools could use to provide bounded options in the absence of defaults.

Package PROJECT_NAME

Re: New tool "gprexec", basically "make with project file"

[Shark8]

On Tuesday, January 15, 2019 at 9:41:04 AM UTC-7, Shark8 wrote:
> 
> Package PROJECT_NAME

Sorry, I accidentally submitted the form while composing my example... which is here:

Package PROJECT_NAME is

   Type Archetectures is ( x86, x86_64, ARM, SPARC, MIPS_V );
   Type Node_Type is (Storage, Processing);
   Type Partition_Type is (Active, Passive);
   Type Compilation_Parameters is record
     CPUs    : Natural := 0;	-- Use as many cores as available.
	 Symbols : Boolean := True;	-- Don't strip symbols.
	 Target  : Archetectures;
	 --...
   end record;
   
   Type Partition( Params : Compilation_Parameters; Style : Partition_Type ) is record
     null; --... Other DSA paramters.
   end record;
   
   Type Node( Style : Node_type ) is record
     Archetecture : Archetectures;
     case Style is
	   when Storage =>    null; --... 
	   when Processing => null; --...
	 end case;
   end record;
   
   Generic
     Params : Compilation_Parameters;
   Procedure Compile;
   
   --- CONCEPTUAL GENERIC PACKAGE
   Generic
     Partitions : Array (Positive range <>) of not null access Partition;
   Package Compiler is
     Procedure Execute;
   End Compiler;
   
   --- CONCEPTUAL BODY FOR COMPILER.
   Package Body Compiler is
     Procedure Execute is
	 Begin
	   For P of Partitions loop
	     declare
		   Procedure Make is new Compile( P.Params );
		 begin
		   Make;
		 end;
	   End loop;
	 End Execute;
   End Compiler;
   
   
End PROJECT_NAME;

Now, obviously there would have to be standardization -- and it would probably work better if "Archetectures" were a parameter to PROJECT_NAME -- because if all config-packages were generic we could "nest" dependencies:

Generic
  Type STANDARD_PARAM is limited private; -- "Configuration standard param"
  with Package P1 is new Project_1( STANDARD_PARAM );
  with Package P2 is new Project_2( STANDARD_PARAM );
  -- P3 depends on P1&2
  with Package P3 is new Project_3( STANDARD_PARAM, P1, P2 );
Package Project_4 is
 -- ... STANDARD STRUCTURE.
End Project_4;

Now, all of that is operating with the idea of using Ada as a config-language, which is doable, but perhaps a bit ugly... It might be a bit better to sit down, think about configurations (esp. in the presence of DSA) and develop an Ada-like language for that. (Perhaps in conjunction with a new Ada IR similar to DIANA, such that this configuration-description "compiles down to" the proper generic-nodes which can then be interpreted by the compiler as the configuration[s] to use; or processed by tools to inter-operate with current tools [ie IR → (GPR_File, Gnatdist_Configuration_File) for GNAT].)