Elaboration of Ada object archive. Possible/Alternatives?

Elaboration of Ada object archive. Possible/Alternatives?

[Gordon Brunton]

Having been fruitless in my search for a solution to my problem I am hoping
someone on this newsgroup can assist.  I am convinced there has to be
someone who has encountered this problem before.

Background:
I'm currently involved in the implementation of a large scale Air Traffic
Control System written primarily written using Ada 83.  The development
environment is Rational Apex on a Solaris platform.  The
integration/delivery platform is HP/UX.

Problem:
There are several components for the current system we intend to reuse from
another system in the product line (These components are written in Ada as
is the rest of the system).  The requirement is that the source code for
these reused components is a non deliverable item.  The source code for the
rest of the system is deliverable however and there is a requirement for the
customer to be able to maintain the system after delivery and thus they need
to be able to compile/link against the components we have not delivered the
source code for.

My intention was to provide an API subsystem housing the components for
which no source code is delivered.  The API subsystem would contain an API
interface and an object archive of the code we are not delivering.

As way of an example, I have an API that looks like (the API is deliverable
code):

foo_api.1.ada:
package foo_api is

  procedure Do_Something;

end foo_api;

foo_api.2.ada:
package body foo_api is

  procedure Do_Something;
  pragma Import (Convention => Ada, Entity => Do_Something);

end foo_api;

Then I have the implementation that looks like (the implementation is the
non deliverable code that will be complied into an object archive):

foo_implementation.1.ada
package foo_implementation is

  procedure Do_Something;
  pragma Export (Convention => Ada, Entity => Do_Something);

end;

foo_implementation.2.ada
package body foo_implementation is

  procedure Do_Something is
  begin
   -- The work is performed here.
  end;

end foo_implementation;

Note that the example above is given only as way of an example.  The actual
API has many interfaces and the implementation is composed of many packages
most of which require some elaboration.

This all works to the extent that I am able to compile all the code and
produce an object archive of the implementation (non deliverable code) with
which to resolve the symbols at link stage.  However, as nothing in the main
program (that calls the API interfaces) includes any of the implementation
directly in it's closure a program error is resultant on execution.

The problem is, is there anything I can do to force the code in the archive
library to be elaborated without doing an explicit pragma elaborate (which
would require me to 'with' the implementation and thereby defeat the whole
purpose of the exercise).

I have encountered the 'pragma Export_Elaboration_Procedure' but can't find
any real examples of its usage (or if it would indeed be able to assist in
my problem).  If anyone has experience using this and feels it may be of use
then please let me know.

I would be grateful if anyone could assist me in providing a resolution to
this problem (or suggest an alternative approach that still meets my needs).
Note that it is preferable not to alter the non deliverable component code.

Thanks in advance.

Gordon Brunton
Senior Software Engineer
Ratheon Systems
(gordon_brunton@raytheon.com)

Re: Elaboration of Ada object archive. Possible/Alternatives?

[Jeff Creem]

I'd contact Rational tech support (and then once you find out that anything
tougher
than a license key causes them to brain lock) and then contact your local
sales rep
who can put you in contact with the local tech rep. The tech reps are
usually very
knowledgeable and are a great resource for handling issues like this.


The problem here is that the approach you take will be somewhat different
with
different compilers so probably the vendor is the best shot. As a general
rule there
is often some way of determining the entry point to the elaboration code and
then calling it.

This may require that you make a special elaboration procedure that calls
multiple entries in
the "proper" order.


"Gordon Brunton" <gkbrunton@home.com> wrote in message
news:ozER5.653999$8u4.9941815@news1.rdc1.bc.home.com...
> Having been fruitless in my search for a solution to my problem I am
hoping
> someone on this newsgroup can assist.  I am convinced there has to be
> someone who has encountered this problem before.
>
> Background:
> I'm currently involved in the implementation of a large scale Air Traffic
> Control System written primarily written using Ada 83.  The development
> environment is Rational Apex on a Solaris platform.  The
> integration/delivery platform is HP/UX.
>
> Problem:
> There are several components for the current system we intend to reuse
from
> another system in the product line (These components are written in Ada as
> is the rest of the system).  The requirement is that the source code for
> these reused components is a non deliverable item.  The source code for
the
> rest of the system is deliverable however and there is a requirement for
the
> customer to be able to maintain the system after delivery and thus they
need
> to be able to compile/link against the components we have not delivered
the
> source code for.
>
> My intention was to provide an API subsystem housing the components for
> which no source code is delivered.  The API subsystem would contain an API
> interface and an object archive of the code we are not delivering.
>
> As way of an example, I have an API that looks like (the API is
deliverable
> code):
>
> foo_api.1.ada:
> package foo_api is
>
>   procedure Do_Something;
>
> end foo_api;
>
> foo_api.2.ada:
> package body foo_api is
>
>   procedure Do_Something;
>   pragma Import (Convention => Ada, Entity => Do_Something);
>
> end foo_api;
>
> Then I have the implementation that looks like (the implementation is the
> non deliverable code that will be complied into an object archive):
>
> foo_implementation.1.ada
> package foo_implementation is
>
>   procedure Do_Something;
>   pragma Export (Convention => Ada, Entity => Do_Something);
>
> end;
>
> foo_implementation.2.ada
> package body foo_implementation is
>
>   procedure Do_Something is
>   begin
>    -- The work is performed here.
>   end;
>
> end foo_implementation;
>
> Note that the example above is given only as way of an example.  The
actual
> API has many interfaces and the implementation is composed of many
packages
> most of which require some elaboration.
>
> This all works to the extent that I am able to compile all the code and
> produce an object archive of the implementation (non deliverable code)
with
> which to resolve the symbols at link stage.  However, as nothing in the
main
> program (that calls the API interfaces) includes any of the implementation
> directly in it's closure a program error is resultant on execution.
>
> The problem is, is there anything I can do to force the code in the
archive
> library to be elaborated without doing an explicit pragma elaborate (which
> would require me to 'with' the implementation and thereby defeat the whole
> purpose of the exercise).
>
> I have encountered the 'pragma Export_Elaboration_Procedure' but can't
find
> any real examples of its usage (or if it would indeed be able to assist in
> my problem).  If anyone has experience using this and feels it may be of
use
> then please let me know.
>
> I would be grateful if anyone could assist me in providing a resolution to
> this problem (or suggest an alternative approach that still meets my
needs).
> Note that it is preferable not to alter the non deliverable component
code.
>
> Thanks in advance.
>
> Gordon Brunton
> Senior Software Engineer
> Ratheon Systems
> (gordon_brunton@raytheon.com)
>
>

Re: Elaboration of Ada object archive. Possible/Alternatives?

[Robert Dewar]

In article <ozER5.653999$8u4.9941815@news1.rdc1.bc.home.com>,
  "Gordon Brunton" <gkbrunton@home.com> wrote:
> Having been fruitless in my search for a solution to my
> problem I am hoping
> someone on this newsgroup can assist.  I am convinced there
> has to be
> someone who has encountered this problem before.

This is indeed a common problem, and one which we have worked
out several approaches for in the GNAT environment which have
worked quite satisfactorily.

THe solution is likely to be somewhat environment and
implementation dependent, so my suggestion is that you
contact Rational support and ask for their advice on
how their system should be used to solve this problem.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Elaboration of Ada object archive. Possible/Alternatives?

[Tom Hargraves]

Hi Gordon,

The Ada LRM has the following "Implementation Advice", so maybe you could
grep the symbol files for "adainit" and have some fun while you're waiting
for the compiler vendor to reply.

If this is a "common problem", then perhaps the Ada LRM has not been
specific enough in this area?

Regards,
Tom H.

B.1 Interfacing Pragmas

39 If an implementation supports pragma Export to a given language, then it
should also allow the main subprogram to be written in that language. It
should support some mechanism for invoking the elaboration of the Ada
library units included in the system, and for invoking the finalization of
the environment task. On typical systems, the recommended mechanism is to
provide two subprograms whose link names are "adainit" and "adafinal".
Adainit should contain the elaboration code for library units. Adafinal
should contain the finalization code. These subprograms should have no
effect the second and subsequent time they are called.

40 Automatic elaboration of preelaborated packages should be provided when
pragma Export is supported.


"Jeff Creem" <jeff@thecreems.com> wrote in message
news:t1fokco5opii74@corp.supernews.com...
I'd contact Rational tech support (and then once you find out that anything
tougher
than a license key causes them to brain lock) and then contact your local
sales rep
who can put you in contact with the local tech rep. The tech reps are
usually very
knowledgeable and are a great resource for handling issues like this.


The problem here is that the approach you take will be somewhat different
with
different compilers so probably the vendor is the best shot. As a general
rule there
is often some way of determining the entry point to the elaboration code and
then calling it.

This may require that you make a special elaboration procedure that calls
multiple entries in
the "proper" order.


"Gordon Brunton" <gkbrunton@home.com> wrote in message
news:ozER5.653999$8u4.9941815@news1.rdc1.bc.home.com...
> Having been fruitless in my search for a solution to my problem I am
hoping
> someone on this newsgroup can assist.  I am convinced there has to be
> someone who has encountered this problem before.
>
> Background:
> I'm currently involved in the implementation of a large scale Air Traffic
> Control System written primarily written using Ada 83.  The development
> environment is Rational Apex on a Solaris platform.  The
> integration/delivery platform is HP/UX.
>
> Problem:
> There are several components for the current system we intend to reuse
from
> another system in the product line (These components are written in Ada as
> is the rest of the system).  The requirement is that the source code for
> these reused components is a non deliverable item.  The source code for
the
> rest of the system is deliverable however and there is a requirement for
the
> customer to be able to maintain the system after delivery and thus they
need
> to be able to compile/link against the components we have not delivered
the
> source code for.
>
> My intention was to provide an API subsystem housing the components for
> which no source code is delivered.  The API subsystem would contain an API
> interface and an object archive of the code we are not delivering.
>
> As way of an example, I have an API that looks like (the API is
deliverable
> code):
>
> foo_api.1.ada:
> package foo_api is
>
>   procedure Do_Something;
>
> end foo_api;
>
> foo_api.2.ada:
> package body foo_api is
>
>   procedure Do_Something;
>   pragma Import (Convention => Ada, Entity => Do_Something);
>
> end foo_api;
>
> Then I have the implementation that looks like (the implementation is the
> non deliverable code that will be complied into an object archive):
>
> foo_implementation.1.ada
> package foo_implementation is
>
>   procedure Do_Something;
>   pragma Export (Convention => Ada, Entity => Do_Something);
>
> end;
>
> foo_implementation.2.ada
> package body foo_implementation is
>
>   procedure Do_Something is
>   begin
>    -- The work is performed here.
>   end;
>
> end foo_implementation;
>
> Note that the example above is given only as way of an example.  The
actual
> API has many interfaces and the implementation is composed of many
packages
> most of which require some elaboration.
>
> This all works to the extent that I am able to compile all the code and
> produce an object archive of the implementation (non deliverable code)
with
> which to resolve the symbols at link stage.  However, as nothing in the
main
> program (that calls the API interfaces) includes any of the implementation
> directly in it's closure a program error is resultant on execution.
>
> The problem is, is there anything I can do to force the code in the
archive
> library to be elaborated without doing an explicit pragma elaborate (which
> would require me to 'with' the implementation and thereby defeat the whole
> purpose of the exercise).
>
> I have encountered the 'pragma Export_Elaboration_Procedure' but can't
find
> any real examples of its usage (or if it would indeed be able to assist in
> my problem).  If anyone has experience using this and feels it may be of
use
> then please let me know.
>
> I would be grateful if anyone could assist me in providing a resolution to
> this problem (or suggest an alternative approach that still meets my
needs).
> Note that it is preferable not to alter the non deliverable component
code.
>
> Thanks in advance.
>
> Gordon Brunton
> Senior Software Engineer
> Ratheon Systems
> (gordon_brunton@raytheon.com)
>
>