You are talking about “ files ” (not package) : what are
responsibilities for this project ?
As a developer ? As a manager ?
And what kind of code is it ? Any tricky implementation or
dependencies ?
Ada is notably portable, so unless the code relies on some specific
pragma or suspicious assumption about the compiler behavior, there
should not be any trouble.
Well, just to give an advice (as we finally do not know a lot), it
seems that elaboration order is a common trap while switching from one
compiler to another (this is not a compiler trouble then, but mostly a
design trouble).
But I guess linking may also be an issue, if multiple parts of the one
application are to be compiled by different compilers.
Does it help ? Did I understood what you were asking about ?
Please, tell : you first suggested that one subset is to be compiled
with one compiler, and the remaining subset with another compiler, and
the latter quote, suggest that all the set is be compiled with one
compiler and then the same with another compiler.
Which is the one to be applied : the first way or the second way ?
[The same post 4 times.]
It would be nice if your posts didn't show up multiple times.
--
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36
You are still not making your question or problem clear, in Ada terms.
To get reasonable answers you should explain what all these "files" have
to do with the desired functionality of the program on one or another
computer.
So you have a computer A with compiler A, and a computer B with compiler
B. The Ada program consists of 1000 "files" (presumably Ada package
declarations and package bodies) that are the same for system A and for
system B. The complete program for system A consists of these 1000
shared files, plus 30 files specific to system A. The complete program
for system B consists of the same 1000 shared files, and 30 other files
specific to system B. The core question is *why* you have 30 different
files for systems A and B:
- Are they simply different versions of the same Ada packages, one
version tailored for system A, the other for system B, but implementing
the same functionality? Tailoring could be necessary for compiler
differences, O/S differences, or computer differences.
- Or do they represent different functionality, so that the complete
program on system A behaves differently from the complete program on
system B? For example, the program on system A may have some added
functionality that is absent from the program on system B, and vice
versa. Do you now want to combine the two so that all functionality
exists on both systems?
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
> On 4 nov, 20:27, ChristopherL <clusard...@aol.com> wrote:
>> So, how can I combine all the files together into 1060 files and
>> compile them with both compilers. I.E.: Take the bundle of 10060
>> files and compile them with compiler A, and do the same for
>> compiler B.
This is compiler dependent. You need to read the compiler
documentation; it will tell you how to specify what files to compile.
In general, keeping the two different sets of 30 files in separate
directories will help.
--
-- Stephe
I'm not sure I understand what you mean by combine.
Manual work seems unneccessary, and maybe the whole
combination approach is not really the best option:
Would it be OK to perform the distinction by system
at run-time, e.g. during program setup by setting
some pointers or by running main loops in instances
of suitable generic instances?
If not, it was suggested to use directories, and instruct
the respective compilers to look for the respective
30 files in these directories. Assuming you
have the typical set of spec files, body files, and
some files containing full subprograms. A directory
setup might look like this:
/1000+-common/
/1000+-common/30-system-A
/1000+-common/30-system-B
Is this something you have in mind:
Package Foo specifies functions for both systems A and B,
but the bodies are different for systems A and B.
I'd put the spec file of package Foo in /1000+-common.
Body files go in the ./30-system-{A,B} subdirectories.
Then I tell the compiler X for system A to look in /1000+-common
and in /1000+-common/30-system-A.
I tell the compiler Y for system B to look in /1000+-common
and in /1000+-common/30-system-B.
The compiler will find specs in the directory of common files,
and bodies either in the subdirectory 30-system-A or 30-system-B,
as specified.
If compiler X should compily for system B, too, I'd say
that in the same way, for another run. And similarly for
compiler Y for system A.
I had hesitated to mention a preprocessor. You can use
M4, or cpp. However, dead code elimination is another
option, stays within the language and insofar seems more
manageable (cases don't get lost accross units
when they are in types, not #conditionals, for example.)
(To seems more manageable to me at least, I have lost hair
in missing #else, missing code, missing test cases, and
similar features of conditional program text.
The separate directories solution (as long as the number
of decisions is small) is no less checkable, and, I think,
no more prone to errors than placing the code between
preprocessor conditionals.)
Small example that reduces the need for conditional
text to one constant. It can be replaced using
a preprocessor (or script or human) that needs not
support conditionals. Dead code elimination may work:
package Control is
type Capacity is range 1 .. 8_000;
type Table_Size is (Small, Big);
for Table_Size use (Small => 10, Big => 1000);
for Table_Size'Size use Capacity'Size;
Mode : constant Table_Size := Small; -- <- adjust per system
procedure Start;
end Control;
with Interfaces;
with Ada.Unchecked_Conversion;
package body Control is
function To_Capacity is new Ada.Unchecked_Conversion
(Table_Size, Capacity);
package Small_System is
procedure Run;
private
Last : constant Capacity := To_Capacity (Small);
Data_Store : array (Capacity range 1 .. Last) of Interfaces.Unsigned_8;
end Small_System;
package Big_System is
procedure Run;
private
Last : constant Capacity := To_Capacity (Big);
Data_Store : array (Capacity range 1 .. Last) of Interfaces.Unsigned_8;
-- ... other differences
end Big_System;
procedure Start is
begin
case Mode is
when Small =>
Small_System.Run;
when Big =>
Big_System.Run;
end case;
end;
package body Small_System is separate;
package body Big_System is separate;
end Control;
We need to know what it is about these packages that results in you having
different versions for the 2 compilers. Some things that differ between
compilers can be handled in a single package; others require that you have
different bodies for the different compilers.
--
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35
> On Nov 5, 11:04�am, "Jeffrey R. Carter"
> <spam.jrcarter....@spam.acm.org> wrote:
>> ChristopherL wrote:
>>
>> > They are different versions of the same Ada packages, one version
>> > tailored
>> > for system A, the other for system B, but implementing the same
>> > functionality.
>>
>> We need to know what it is about these packages that results in you having
>> different versions for the 2 compilers. Some things that differ between
>> compilers can be handled in a single package; others require that you have
>> different bodies for the different compilers.
>>
>
> One requires renaming routines, some of the pragmas to be removed, and
> some of the overloaded operators to be removed.
The general approach to this is to use separate files in separate
directories, and use compiler-specific techniques to select the right
directory at compile time.
This is easy with GNAT project files; other compilers have other ways
to do it.
--
-- Stephe
As a person who uses Google Groups, it would be nice if
<clusard...@aol.com>'s posts showed up at all! I never see them.