Re: Conditional compilation

[jb@rti.UUCP (Jeff Bartlett)]

In article <28254@clyde.ATT.COM>, rds@moss.ATT.COM writes:
> 
> If this is, in fact, what the LRM intends to say it is an insufficient
> method for conditional compilation. Consider the following scenario:
> 
> Package A is generic with a generic type parameter. Package B is generic
> with the same generic parameter. A particular system requires only
> package A and another system requires both A & B. 
> 
> B's compilation requires the existance of an instantiated version of A.

1. if the customer is to do this instantiation of A then they must receive
   the source for B.

> It is important that the customer with system A who does not need package B
> not get package B and not neccesarily know of the existance of package B.

2. This implies that there are no packages in the minimal system that depend
	on B
     ==> no shipped executables need package B.
     ==> package B is supplied to customer in source or in a shipped
         compilation library

> An appropriate solution (in a C environment) is to conditionally
> include the code for package B with package A at compilation time.
 
The C source would have:
	#ifdef EXTRA_FEATURES
	#include "package_b.c"
	#endif

- the existance of package B should not be revealed in limited systems.
- the C source would reveal the existance of package B
- C is appropiate solution.
==> the customers do not get the source.

for the limited system:
    - if it is in a shipped compilation library compile everything
      and delete the interface and body for package B from the library

    - not supplied B in source form (for the case of user instantiated A and
      '#include "package_b.c"' is acceptable ).

    - these are separately compilable units.  Just don't compile the
      file containing package B.

Any bad assumptions or flaws in logic?

Are the any tests in the Ada compiler validation suite that checks that
compilation unit Y does not depend on the interface of B in the compilation
library?

    with B;
    procedure Y is
       K : B.TYPE1;  -- unref'd, may be removed
    begin
	if FALSE then
	    B.ROUTINE1;
	    K := 5;
	end if;
    end Y;

DecAda V1.5 has the library dependancy but no code or stack space was generated.

LRM 10.1.1.6 states that the 'with' will cause a library dependancy.  Should
the optimizer be allowed to revoke it or does a 'with' imply an explict
elaboration of package B regardless of the fact that there are no references
to B in procedure Y.

Of course this isn't allowed

   procedure Y is
   begin
      if FALSE then
	 declare
	    with B;
	    K : B.TYPE1;  -- unref'd, may be removed
	 begin
	    B.ROUTINE1;
	    K := 5;
	 end;
      end if;
   end Y;

if it were then the compiler could safely assume that the elaboration of B
was not needed.
     
> Richard DeSimine
> AT&T Bell Laboratories
> (201) 386-2059

Jeff Bartlett
Center for Digital Systems Research
Research Triangle Institute
jb@rti.rti.org		...mcnc!rti!jb