Binding and linking non-withed packages into an executable

Binding and linking non-withed packages into an executable

[Marc A. Criley]

(I vaguely recall this topic previously being discussed in some forum
somewhere but have been unable to locate it.)

I want to be able to have a compiled package bound and linked in with an Ada
executable, despite there being no "with" of that package. The reason is
that there are "access procedure variables" in the main set of code, which
this peripheral package can set to its own procedures during the elaboration
of the package. This is bound to be compiler-specific, so I'm using GNAT
3.15p on Linux.

Here's a toy illustration:

-- A package with a "callback variable"
package Back_Caller is
   type Callback is access procedure;
   Cb : Callback;
end Back_Caller;

-- The main program that invokes that callback variable.
with Back_Caller;
procedure Cb_Main is
begin
  Back_Caller.Cb.all;
end Cb_Main;

-- The peripheral package that supplies the callback...
package CB_Provider is
   procedure My_Callback;
end CB_Provider;

-- ...that the callback variable is set to during pkg elaboration.
with Text_IO; use Text_IO;
with Back_Caller;
package body CB_Provider is
   procedure My_Callback is
   begin
      Put_Line("Invoking callback");
   end My_Callback;
begin
   Back_Caller.CB := My_Callback'access;
end CB_Provider;


Invoking gnatmake on Cb_Main compiles just the Back_Caller package and
Cb_Main procedures, as one would expect. How can I get the CB_Provider
package bound (so it'll be elaborated) and linked in?

I've looked at the various gnatbind options, but they're more geared for "no
main" or "non-Ada main" situations.

Obviously I can have a "configuration package" that with's the "peripheral"
packages and is withed by the main, but I'd like to make the inclusion of
such packages a build, rather than compile, issue. This way new callback
packages can be brought in or omitted as needed (the actual app is of course
more sophisticated than the above toy), so no actual software would have to
change.

Thanks for any help.

Marc A. Criley

Re: Binding and linking non-withed packages into an executable

[Stephen Leake]

"Marc A. Criley" <mcNOSPAM@mckae.com> writes:

> Obviously I can have a "configuration package" that with's the "peripheral"
> packages and is withed by the main, but I'd like to make the inclusion of
> such packages a build, rather than compile, issue. This way new callback
> packages can be brought in or omitted as needed (the actual app is of course
> more sophisticated than the above toy), so no actual software would have to
> change.

I define "actual software" as "anything in CVS". In your desired
system, the Makefile would have to change. In standard Ada, one .adb
file would have to change. Either way, it's one file in CVS.

What is the actual gain over doing it in a non-standard way?

-- 
-- Stephe

Re: Binding and linking non-withed packages into an executable

[Ludovic Brenta]

Stephen Leake <stephen_leake@acm.org> writes:

> "Marc A. Criley" <mcNOSPAM@mckae.com> writes:
> 
> > Obviously I can have a "configuration package" that with's the
> > "peripheral" packages and is withed by the main, but I'd like to
> > make the inclusion of such packages a build, rather than compile,
> > issue. This way new callback packages can be brought in or omitted
> > as needed (the actual app is of course more sophisticated than the
> > above toy), so no actual software would have to change.
> 
> I define "actual software" as "anything in CVS". In your desired
> system, the Makefile would have to change. In standard Ada, one .adb
> file would have to change. Either way, it's one file in CVS.
> 
> What is the actual gain over doing it in a non-standard way?

Allowing customers to provide their own callbacks, without recompiling
the app or having access to the source code?  Like in a plug-in
system?

How about compiling the plug-ins separately from the application?
Then the application reads some sort of configuration file, or
directory, or registry of plug-ins, and dlopen()s the appropriate
library at run time.  I understand there exists an Ada binding to
dlopen() already.  Would this solve your problem?

-- 
Ludovic Brenta.

Re: Binding and linking non-withed packages into an executable

[Stephen Leake]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
> 
> > "Marc A. Criley" <mcNOSPAM@mckae.com> writes:
> > 
> > > Obviously I can have a "configuration package" that with's the
> > > "peripheral" packages and is withed by the main, but I'd like to
> > > make the inclusion of such packages a build, rather than compile,
> > > issue. This way new callback packages can be brought in or omitted
> > > as needed (the actual app is of course more sophisticated than the
> > > above toy), so no actual software would have to change.
> > 
> > I define "actual software" as "anything in CVS". In your desired
> > system, the Makefile would have to change. In standard Ada, one .adb
> > file would have to change. Either way, it's one file in CVS.
> > 
> > What is the actual gain over doing it in a non-standard way?
> 
> Allowing customers to provide their own callbacks, without recompiling
> the app or having access to the source code?  

Ok, that's reasonable. But not what the OP asked for.

> Like in a plug-in system?

That would be good.

> How about compiling the plug-ins separately from the application?
> Then the application reads some sort of configuration file, or
> directory, or registry of plug-ins, and dlopen()s the appropriate
> library at run time. I understand there exists an Ada binding to
> dlopen() already. Would this solve your problem?

Not my problem. Possibly the OPs problem.

-- 
-- Stephe

Re: Binding and linking non-withed packages into an executable

[Robert A Duff]

"Marc A. Criley" <mcNOSPAM@mckae.com> writes:

> (I vaguely recall this topic previously being discussed in some forum
> somewhere but have been unable to locate it.)
> 
> I want to be able to have a compiled package bound and linked in with an Ada
> executable, despite there being no "with" of that package. The reason is
> that there are "access procedure variables" in the main set of code, which
> this peripheral package can set to its own procedures during the elaboration
> of the package. This is bound to be compiler-specific, so I'm using GNAT
> 3.15p on Linux.
> 
> Here's a toy illustration:
> 
> -- A package with a "callback variable"
> package Back_Caller is
>    type Callback is access procedure;
>    Cb : Callback;
> end Back_Caller;
> 
> -- The main program that invokes that callback variable.
> with Back_Caller;
> procedure Cb_Main is
> begin
>   Back_Caller.Cb.all;
> end Cb_Main;
> 
> -- The peripheral package that supplies the callback...
> package CB_Provider is
>    procedure My_Callback;
> end CB_Provider;
> 
> -- ...that the callback variable is set to during pkg elaboration.
> with Text_IO; use Text_IO;
> with Back_Caller;
> package body CB_Provider is
>    procedure My_Callback is
>    begin
>       Put_Line("Invoking callback");
>    end My_Callback;
> begin
>    Back_Caller.CB := My_Callback'access;
> end CB_Provider;
> 
> 
> Invoking gnatmake on Cb_Main compiles just the Back_Caller package and
> Cb_Main procedures, as one would expect. How can I get the CB_Provider
> package bound (so it'll be elaborated) and linked in?

I think you have to say "with CB_Provider;" somewhere in your system.

By the way, there seems to be no need to export My_Callback.  You could
declare the package spec as:
   package CB_Provider is
      pragma Elaborate_Body;
   end CB_Provider;

> I've looked at the various gnatbind options, but they're more geared for "no
> main" or "non-Ada main" situations.
> 
> Obviously I can have a "configuration package" that with's the "peripheral"
> packages and is withed by the main,

I think that's what you need to do.

>... but I'd like to make the inclusion of
> such packages a build, rather than compile, issue. This way new callback
> packages can be brought in or omitted as needed (the actual app is of course
> more sophisticated than the above toy), so no actual software would have to
> change.

Why?  Build scripts are software!

- Bob

RE: Binding and linking non-withed packages into an executable

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Marc A. Criley [mailto:mcNOSPAM@mckae.com]
...
| Obviously I can have a "configuration package" that with's 
| the "peripheral"
| packages and is withed by the main, but I'd like to make the 
| inclusion of
| such packages a build, rather than compile, issue. This way 
| new callback
| packages can be brought in or omitted as needed (the actual 
| app is of course
| more sophisticated than the above toy), so no actual software 
| would have to
| change.

As others here, I think that editing one Ada source isn't much more work
than editing some Makefile.
And I much more trust the Ada compiler than external production tools to
include the right packages in my exe.


-- 
Lionel Draghi