On 4 nov, 19:53, ChristopherL <clusard...@aol.com> wrote:
> How would you go about compiling your code?
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 ?
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.
> What are the various tricks of the trade, and could you supply > small examples segnents of code to demonstrate.
> Thanks
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 ?
ChristopherL wrote: > On Nov 4, 10:53 am, ChristopherL <clusard...@aol.com> wrote: >> Hello,
>> In about a year, I will be presented with the task of making the same >> large program compilable with two very different Ada compilers.
>> Sorry, I do not know the names of the compilers or computers that I'll >> be working with. The decision has not been reached at this time. The >> manufacturer support on one or both of these compilers may be almost >> non-existant.
>> How would you go about compiling your code?
>> Thanks
> O'kay, I have some additional information to add!
> I will know what files to use to compile with each compiler. In other > words, I will be told this program (group of files) compiles on this > computer using this compiler, and I will be told the same thing for > the second compiler/computer. Again, they will be compiling the same > program with minor differences between them. The differences are in > about 30 files. So, basically there are two groups of 30 files. Each > compiler will use the program with different a different set of 30 > files. > There are about 1000 files in the entire program. So compiler A will > compile 1030 files and compiler B will compile 1000 files plus > different 30 files. The 30 files are required to compile with compiler > A, and a different set of 30 files are required to compile the 1000 > files with compiler B.
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?
> 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.
> On Nov 5, 2:02 am, Niklas Holsti <niklas.hol...@tidorum.invalid> > wrote: >> - 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.
> 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.
> Query: Is there some way I can combine the two sets of 30 files into > one set of > 30 files.
> Or, is it best to just forget trying to combine these two sets of 30 > files in some way. And, just manually compile the appropriate set of > 30 files on what ever system I am working on. Does anyone have any > ideas.
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:
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.
> Does Ada have anything similar to the following C preprocessor > directives:
> #ifdef TABLE_SIZE > --Add Code Here > #elif TABLE_SIZE < 50 > --Add Code Here > #endif
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;
> 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.
-- Jeff Carter "Sheriff murdered, crops burned, stores looted, people stampeded, and cattle raped." Blazing Saddles 35
ChristopherL <clusard...@aol.com> writes: > 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.
|
