* Re: ifdef replacement for GNAT [not found] <352287EE.1CFB@tolstoy.mdc.com> @ 1998-04-08 0:00 ` John T Vegezzi 312C M 237110 1998-04-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 16+ messages in thread From: John T Vegezzi 312C M 237110 @ 1998-04-08 0:00 UTC (permalink / raw) For those interested, gnatprep is a preprocessing utility included in the GNAT distribution which will support #ifdef type conditional compilations. gnatprep produces an output file which forms the input to the compiler. It is not as transparent as the C preprocessor - See the man page for details. -- John T Vegezzi (314) 233-3589 j_vegezz@tolstoy.mdc.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-08 0:00 ` ifdef replacement for GNAT John T Vegezzi 312C M 237110 @ 1998-04-09 0:00 ` Robert Dewar 1998-04-10 0:00 ` Dirk Zoller 0 siblings, 1 reply; 16+ messages in thread From: Robert Dewar @ 1998-04-09 0:00 UTC (permalink / raw) John said <<For those interested, gnatprep is a preprocessing utility included in the GNAT distribution which will support #ifdef type conditional compilations. gnatprep produces an output file which forms the input to the compiler. It is not as transparent as the C preprocessor - See the man page for details. >> I have no idea what "not as transparent as the C preprocessor" means, but note that gnatprep, unlike the C preprocessor, understands Ada tokens and will pass through arbitrary Ada text without difficulties, unlike the C preprocessor which will choke on some constructs (such as attributes) because they do not look like C tokens. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-09 0:00 ` Robert Dewar @ 1998-04-10 0:00 ` Dirk Zoller 1998-04-10 0:00 ` Robert Dewar 1998-04-11 0:00 ` Geert Bosch 0 siblings, 2 replies; 16+ messages in thread From: Dirk Zoller @ 1998-04-10 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > John said > > <<For those interested, gnatprep is a preprocessing utility included in > the GNAT distribution which will support #ifdef type conditional > compilations. gnatprep produces an output file which forms the input to > the compiler. The designers of Ada have thought of so many things. Very impressive. Of the procedural languages I know it is the one where I can express the most in terms of the plain standard language. With the exception of nonstandard stuff imposed on me by the environment I'm programming for. These preprocessor conditionals are missing. Or am I missing something? How is an Ada project (GNAT) being kept portable among various Unices and say, Win32? Assume there is something special to be done in all environments. Without using a nonstandard tool like gnatprep that is. -- Dirk Zoller <Dirk.Zoller_@_rhein-main_._netsurf_._de> Remove '_' from the e-mail adress. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-10 0:00 ` Dirk Zoller @ 1998-04-10 0:00 ` Robert Dewar 1998-04-11 0:00 ` nabbasi ` (4 more replies) 1998-04-11 0:00 ` Geert Bosch 1 sibling, 5 replies; 16+ messages in thread From: Robert Dewar @ 1998-04-10 0:00 UTC (permalink / raw) Dirk asks <<How is an Ada project (GNAT) being kept portable among various Unices and say, Win32? Assume there is something special to be done in all environments. Without using a nonstandard tool like gnatprep that is. >> The Steelman requirements prohibited the inclusion of preprocessing in the Ada language, which may surprise you. What may surprise you more is that I and many others think this is a *good thing*. We provide gnatprep for our users, but we do NOT use it ourselves in the GNAT system. The proper approach for achieving target dependence is to follow two steps (a) encapsulte the target dependence down to the minimum level (b) Provide separate target dependent units for these remaining functions This has worked well in the GNAT project. We do use some conditional compilation in the small parts of the runtime written in C (probably conditions are overused here ...) Indeed, the use of conditional compilation has many disadvantages: 1. It tends to run amok. People throw in #ifdef's without a moment's thought about how to make the code more common, and avoid the need for target dependent conditionalization. 2. Since deleted code is not syntax or semantic checked, you don't even know that your code will compile correctly for different combinations of checks. By avoiding the inclusion of preprocessing facilities in the language, you discourage their use. This discouragement is definitely a good thing. Yes, people used to C find this surprising, but I have worked on several large Ada systems that managed just fine in dealing with target dependencies without resorting to conditional compilation. Going back to GNAT, the front end is almost entirely target independent. The backend is much more target independent than you might suppose. The great majority of target dependence is encapsulated in the configuration file, there is one such file for each target. The runtime is mostly target dependent, with the exception of five files that provide the low level tasking interface. These files have multiple versions for different targets. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-10 0:00 ` Robert Dewar @ 1998-04-11 0:00 ` nabbasi 1998-04-11 0:00 ` Larry Kilgallen 1998-04-13 0:00 ` Richard Kenner 1998-04-11 0:00 ` Larry Kilgallen ` (3 subsequent siblings) 4 siblings, 2 replies; 16+ messages in thread From: nabbasi @ 1998-04-11 0:00 UTC (permalink / raw) In article <dewar.892261504@merv>, dewar@merv.cs.nyu.edu says... >The proper approach for achieving target dependence is to follow two steps > > (a) encapsulte the target dependence down to the minimum level > > (b) Provide separate target dependent units for these remaining functions > Prof. Dewar, let me try to see what you mean by point (a) above by an example (I am also one of those who learn better by examples, for no other reason other than to be clear on what things mean): Lets assume we have UNIX and VMS (for the purpose of this example). Lets assume one wants to create a child process. on UNIX one calls fork(), on VMS one calls vfork(). There are nowadays 3 main methods of how to do this. first solution ============= cc -DUNIX program.c program.c +--------------------------------------+ | #if defined(VMS) | | status = vfork() | | #else | | #if defined(UNIX) | | status= fork() | | #else | | #error "unsupported platform" | | #endif /* UNIX */ | | #endif /* VMS */ | +--------------------------------------+ Now, I do not like the above myself, for the same reason you say, it also makes the code hard to read and maintain. second solution ================ The other approach is to do this: cc -DUNIX program.c program.c +-----------------------------+ |#include "program.h" | | status= GENERIC_fork(); | +-----------------------------+ program.h +---------------------------------+ | #if defined(VMS) | | #define GENERIC_fork vfork | | #else | | #if defined(UNIX) | | #define GENERIC_fork fork | | #else | | #error "unsupported system" | | #endif | | #endif | +---------------------------------+ This above is a little better since the main source code is not cluttered, and the ifdef stuff is kept in one header file, but it also suffer from some of the same problems. It also has an additional problem which is against the "what you see is what you get". i.e. one looks at the source code in program.c, they do not know actually what the call will turn up to be without looking around in some other header files to find out. (another variation on the above is to use a compiler directive (as in -Dfork=vfork) to make replacement of all "fork" tokens to become "vfork". This assumes that the original files used the fork call. This also is a bad solution, as it is confusing and is not what you see is what you get when looking at the code. but can be useful to eliminate the need to edit many files manually or add ifdef everywhere where the call is made. third solution ============== have one file (package in Ada terms) that contains all the specific platform functions that are not command to other platforms. so in the above example we can have program.c VMS.c UNIX.c +---------------------------+ +-------------------+ +---------------------+ | | |#include "unistd.h"| |#include "unistd.h" | | #include "program.h" | |int GENERIC_fork() | | int GENERIC_fork() | | status = GENERIC_fork() | | { | |{ | | | | return vfork(); | | return fork(); | +---------------------------+ | } | |} | +-------------------+ +---------------------+ program.h +--------------------------+ | int GENERIC_fork(); | +--------------------------+ Now, this is better. When on UNIX, the makefiles will link the common source code against the UNIX specific files, and when on VMS the makefiles will be directed to link against the VMS specific platform dependent file(s) as in: on VMS: cc -c VMS.c cc program.c VMS.o on UNIX: cc -c UNIX.c cc program.c UNIX.o This solution I like the most of the three. first, the common source code is free of ifdef stuff. and so easier to read and maintain. it also easy to find where all the platform specific stuff is located. the platform specific file(s) should also be named to reflect the platform, but this is minor point. The only problem with the third solution is that one needs to design the program from the start with this in mind. i.e. any operation which could possibly be different on different platforms must be not called directly from the "common" body of the program, but instead wrap it and make the platform specific calls from the platform specific module(s). many time, people do not do this (how many of us who code in c/c++ wraps a fork() call for example? or an open() or etc..etc.., but later on, when one wants to port the program to a different platform, and then find out that that call is not exactly the same as on the first platform, the easy and the quickest way will be to resort to solution 1 above, in particular when the program needs to be done by Monday morning :) I think the hardest thing is to foresee in advanced what the platform specific calls will be. or what the platform specific components will be. for example reading a directory file I do not think is available on windows as is done on UNIX. and so this have to be wrapped (or abstracted). I assume what you meant by point (a) is something along the lines of the third solution above. right? I am not sure about your point (b) above, since it seems to be folded into (a), at least in the way I thought about (a). thanks, Nasser ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-11 0:00 ` nabbasi @ 1998-04-11 0:00 ` Larry Kilgallen 1998-04-13 0:00 ` Richard Kenner 1 sibling, 0 replies; 16+ messages in thread From: Larry Kilgallen @ 1998-04-11 0:00 UTC (permalink / raw) In article <6gn4q1$ee6@drn.newsguy.com>, nabbasi@earthlink.net writes: > I think the hardest thing is to foresee in advanced what the platform > specific calls will be. or what the platform specific components will be. > > for example reading a directory file I do not think is available on windows > as is done on UNIX. and so this have to be wrapped (or abstracted). This does not seem so hard to me if you start with multiple operating systems not particularly related to each other (i.e., not all Unix, not all Windows, etc.). After you have found the operations which differ among Solaris X86 (always pick the smaller subset), MicroVMS (yes, it had Ada), Windows 3.1, OS/2 and MVS, you have minimized your future work in discovering new areas which are uncomon. The worst thing is to start with one operating system and presume that all others are like it. Windows programmers and Unix programmers seem to be most prone to this pattern; the rest of us know from the start that we are in a minority :-). Larry Kilgallen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-11 0:00 ` nabbasi 1998-04-11 0:00 ` Larry Kilgallen @ 1998-04-13 0:00 ` Richard Kenner 1 sibling, 0 replies; 16+ messages in thread From: Richard Kenner @ 1998-04-13 0:00 UTC (permalink / raw) In article <6gn4q1$ee6@drn.newsguy.com> nabbasi@earthlink.net writes: >Prof. Dewar, let me try to see what you mean by point (a) above by >an example (I am also one of those who learn better by examples, for no >other reason other than to be clear on what things mean): > >Lets assume we have UNIX and VMS (for the purpose of this example). > >Lets assume one wants to create a child process. on UNIX one calls fork(), >on VMS one calls vfork(). There are nowadays 3 main methods of how to >do this. Let me give my "take" on this, which is that you can't give a meaningful answer based on only *one* difference. If everything is portable except for one thing, it's hard to make a strong case about which way to handle that single non-portable thing. But there isn't just one thing; there are many. And there are also many more than two systems. So the whole point is to establish a methodology for handling the non-portable things and you can't illustrate that well with one thing and two systems. One way you do it is by abstracting them. You make a list of each of the areas of non-portability and find an interface that works for all systems for each of them. Then you can have one module that handles all the non-portablilities. Another is to try to find commonalities and conditionalizations that aren't necessarily system dependent. So suppose you find something that can be done one of two ways (e.g., big or little endian). Rather than conditionalizing each place with "systems A, B, C, D, and E are this way". Say "big endian is this way and little endian is this way". Then have a configuration file for each system saying which of the attributes is true for it. Very roughly speaking, the first approach is typically the way GNAT and GCC handles *host* dependencies and the latter is the way it handles *target* dependencies. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-10 0:00 ` Robert Dewar 1998-04-11 0:00 ` nabbasi @ 1998-04-11 0:00 ` Larry Kilgallen 1998-04-11 0:00 ` raw ` (2 subsequent siblings) 4 siblings, 0 replies; 16+ messages in thread From: Larry Kilgallen @ 1998-04-11 0:00 UTC (permalink / raw) In article <dewar.892261504@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > The proper approach for achieving target dependence is to follow two steps > > (a) encapsulte the target dependence down to the minimum level > > (b) Provide separate target dependent units for these remaining functions So is the build variance then done by maintaining multiple control files for your "Make" utility, or do you have a tool to generate those on the fly? (I realize one might be able to learn this by studying GNAT source, but I am looking for an easy answer. I promise it is not homework from a class :-). Larry Kilgallen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-10 0:00 ` Robert Dewar 1998-04-11 0:00 ` nabbasi 1998-04-11 0:00 ` Larry Kilgallen @ 1998-04-11 0:00 ` raw 1998-04-13 0:00 ` Michael F Brenner 1998-04-14 0:00 ` ifdef replacement for GNAT Jean-Pierre Rosen 4 siblings, 0 replies; 16+ messages in thread From: raw @ 1998-04-11 0:00 UTC (permalink / raw) In article <dewar.892261504@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > The Steelman requirements prohibited the inclusion of preprocessing in > the Ada language, which may surprise you. What may surprise you more is > that I and many others think this is a *good thing*. The second statement did not surprise me; the first one did. I looked at Steelman at http://www.adahome.com/History/Steelman/steelman.htm but I'm still not sure where it prohibits preprocessing. It lists reliability and maintainability among the goals, which would imply this but is not very specific. It talks about conditional compilation; in 6C, it says "Only the selected branch shall be compiled when the discriminating condition is a translation time expression." (regarding the conditional control structure), so it would seem that Ada doesn't need #ifdef because it has if. I'd guess you meant the statement from 13G that "Translators shall do full syntax and type checking" which would rule out text preprocessing (given the various requirements on syntax and types); is this correct? -- MJSR -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-10 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1998-04-11 0:00 ` raw @ 1998-04-13 0:00 ` Michael F Brenner 1998-04-13 0:00 ` Larry Kilgallen 1998-04-14 0:00 ` ifdef replacement for GNAT Jean-Pierre Rosen 4 siblings, 1 reply; 16+ messages in thread From: Michael F Brenner @ 1998-04-13 0:00 UTC (permalink / raw) Robert > The proper approach for achieving target dependence is > to follow two steps > (a) encapsulate the target dependence down to the minimum level > (b) Provide separate target dependent units for these > remaining functions > ... multiple implementations for different targets ... These are good steps. However, there still needs to be a need for conditional compilation for three reasons. First, multiple implentations (function bodies or package bodies, say) for different targets IS conditional compilation. Second, this kind of conditional compilation is not supported within the language, even though it is required for multiple targets. There is no question of whether conditional compilation is needed or used. The question is whether the conditional compilation that we have to do is standard across compilers and tools. Currently the required conditional compilation is not standardized, and each compiler does it its own way. This is a serious language issue that is easily and cheaply fixed. Third, there is a limit to step (a), encapsulation. The language permits an efficient IF FALSE or IF MACHINE=DOS or IF INTERRUPT_LEVELS=15 to be optimized away at runtime, but only in the executable portion of the code. In the declarations the following types of target dependent code cannot be handled within the language, but must resort to non-standard ways of managing the visible parts, not just the implementations: A. Different pragmas or pragma arguments B. Different representation specifications (bit lengths & starts) C. Different types (signed versus unsigned) D. Different implementations of points (integer versus record) E. Different interrupt locations for interrupt handlers F. Different ways of addressing virtual memory G. Different ways of addressing absolute memory H. Different data structures for accomplishing software interrupts I. Different memory-mapped locations for hardware devices J. Different ways of handling integers larger than integer'last K. Number of levels of pointers required to interface to C vs. Java L. Different elements in records for interface to different operating systems Other things like URL formats, bit ordering, filenames, end-of-line-string, end-of-file-string, maximum filename, temporary directory location, directory separator character, byte ordering, numerical and string constants, bit patterns for interrupts, etc., can be done with a configuration package. Looking over the code here written that requires conditional compilation, the following suggestion comes to mind for Ada 2005X: Add into the Ada language a package streaming_IO, which has nothing to do with stream_IO, but instead has the following characteristics. On INPUT Ada will set up reliable streams of bytes from the following sources: directories, virtual memory, absolute memory, serial ports, parallel ports, SCSI ports, key-down presses, key-up presses, mouse-down presses, mouse-up presses, mouse movements (sampled at a selectable rate), screen touches, keypad key-down presses, keypad key-up presses, analog audio input, MIDI, Ethernet packets, standard input, disk files, URLs on the Net, sense lights, tablet control stick, joystick, and so forth for all input ports on the computer. On OUTPUT Ada will set up reliable streams of bytes to the following sinks: directories, virtual memory, absolute memory, serial ports, parallel ports, SCSI ports, sense lights, screen text, screen pixels, speaker, sound boards, MIDI, Ethernet, standard output, disk files, URLs on the Net, lighting up a character of a given size in a given font at a given screen location, etc., for all output ports on the computer. These should be done in such a manner that the user can add additional device streaming_IO streams. The lack of this kind of reliable streaming is what caused the problems with windowing systems today: over-reliance on mouse movement and mouse icon selection, inversion of the main program so that the Windowing System call the program when it detects an input rather than the program taking from whatever stream it desires, and the difficulty of programming windowing systems because (in order to become the main program) the windowing system must restrict the application from doing most of the things it wants to do. There is a strong relationship between these two problems: the lack of conditional code in Ada and the need for device streaming. They are related because almost all of the conditional code is the result of programming reliable device drivers for device streams. The need for conditional compilation of any kind is reduced significantly when the user has direct access to the byte streams coming in from files, ports, directories, URLs, and keyboard interrupts, and can light up pixels on the screen in a portable manner. If Ada standardizes a realtime speed way of directly getting to the hardware, there would probably be no reason for desiring any conditional compilation (outside of the built-in generic instantiation for switching types and their representations), CASE statements and IF statements. The Unix, DOS, Windows 3.1, Windows 9x, Windows NT, Posix, Mac HFS, Solaris, VMS, etc., systems are close enough to permit these streams to be implemented in a standard manner with realtime response. VMS files would NOT go through the record manager, but would be channel programmed so they are given to the user as a stream of bytes, of course. And those operating systems with defects (for example, do not support key down-strokes) would simply never have any inputs on those streams. Defective hardware (for example, missing parallel port or those that use and ISP instead of being hot on the Net) would have an exception: raise missing_hardware. There are approximately 10,000 things that Ada has to do to support applications, divided into various device streams and various data structures. It should be our goal to have all these 10,000 things implemented as external packages by 2005, so that at that time, the revision of the language can concentrate on fixing the small number of efficiency bugs in the language design, eliminating the last of the rational reasons for avoiding the use of Ada. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-13 0:00 ` Michael F Brenner @ 1998-04-13 0:00 ` Larry Kilgallen 1998-04-15 0:00 ` Ada Programming Environment [was ifdef replacement for GNAT] Nick Roberts 0 siblings, 1 reply; 16+ messages in thread From: Larry Kilgallen @ 1998-04-13 0:00 UTC (permalink / raw) In article <6gt6ij$q6o@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes: > These are good steps. However, there still needs to be a need for > conditional compilation for three reasons. Regardless of the presence of reasons for supporting inline conditional compilation, I believe the current state of affairs is the correct one, due to the overwhelming strong reason for _not_ supporting it -- namely that it will get abused. Take a look at any multi-platform C program. Larry Kilgallen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Ada Programming Environment [was ifdef replacement for GNAT] 1998-04-13 0:00 ` Larry Kilgallen @ 1998-04-15 0:00 ` Nick Roberts 0 siblings, 0 replies; 16+ messages in thread From: Nick Roberts @ 1998-04-15 0:00 UTC (permalink / raw) Aha, but Larry, you miss Michael's point: the Ada standard does not prescribe the way in which different 'versions' of code (e.g. package bodies) are selected for compilation into a version of a program. So supplier A provides one method, supplier B provides another, and so on. This is the sort of anarchy which Ada was intended to prevent. Of course, this issue goes beyond just conditional compilation, to the (fairly well discussed) issue of the Ada programming/development environment (APSE or whatever). (Along with others) I would suggest that one of the broad issues Ada 200X should address is the issue of the programming environment. Whilst, doubtless, much would be impossible to standardise, I feel that much could be; and it would surely be a great boon to Ada programmers everywhere to have even a partially standardised environment to work in. I realise there are things like COE out there, but they all have problems (as regards wider implementation). And, with respect, they are not written by the talented people who created Ada (83 & 95), nor are they subject to the same rigorous review process. Michael's discursion on the subject of I/O (a classic Brennerism (MFB is _unique_)) is (to me) fascinating. Mentioning no names, there are some real-time operating systems which use a central 'software bus' in a way very similar to what Michael describes. And the idea works provably well, too. A lesson there, I feel sure. For those of you who are not studied in Turing (shame on you!:-), it is perhaps interesting to note that every program is just a means of translating an input stream into an output stream. Some programs can even do it backwards ;-> -- Nick Roberts, Croydon, UK Nick.Roberts@dial.pipex.com Larry Kilgallen wrote in message <1998Apr13.124600.1@eisner>... |In article <6gt6ij$q6o@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes: | |> These are good steps. However, there still needs to be a need for |> conditional compilation for three reasons. | |Regardless of the presence of reasons for supporting inline conditional |compilation, I believe the current state of affairs is the correct one, |due to the overwhelming strong reason for _not_ supporting it -- namely |that it will get abused. Take a look at any multi-platform C program. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-10 0:00 ` Robert Dewar ` (3 preceding siblings ...) 1998-04-13 0:00 ` Michael F Brenner @ 1998-04-14 0:00 ` Jean-Pierre Rosen 4 siblings, 0 replies; 16+ messages in thread From: Jean-Pierre Rosen @ 1998-04-14 0:00 UTC (permalink / raw) Robert Dewar a �crit dans le message ... >Dirk asks > ><<How is an Ada project (GNAT) being kept portable among various Unices >and say, Win32? Assume there is something special to be done in all >environments. Without using a nonstandard tool like gnatprep that is. >>> > >The Steelman requirements prohibited the inclusion of preprocessing in >the Ada language, which may surprise you. What may surprise you more is >that I and many others think this is a *good thing*. > >We provide gnatprep for our users, but we do NOT use it ourselves in >the GNAT system. > >The proper approach for achieving target dependence is to follow two steps > > (a) encapsulte the target dependence down to the minimum level > > (b) Provide separate target dependent units for these remaining functions > Note that library packages renaming can be handy in managing this approach. You define for example: package My_Interface_Unix is... package My_Interface_Win32 is... and then: with My_Interface_Win32; package My_Interface renames My_Interface_Win32; and use My_Interface all over the place. If you change operating system, you only need to change the renaming in only one place. Not more work than changing a #define. -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-10 0:00 ` Dirk Zoller 1998-04-10 0:00 ` Robert Dewar @ 1998-04-11 0:00 ` Geert Bosch 1998-04-12 0:00 ` Haug Buerger 1 sibling, 1 reply; 16+ messages in thread From: Geert Bosch @ 1998-04-11 0:00 UTC (permalink / raw) Dirk Zoller <duz> wrote: ``How is an Ada project (GNAT) being kept portable among various Unices and say, Win32? Assume there is something special to be done in all environments. Without using a nonstandard tool like gnatprep that is.'' Very easy: put system dependent stuff in a package with a well defined interface (spec) and use different bodies for different systems. You'd like to make this system dependent part as small as possible, but this is a good design principle anyway. When you want to add a new system you just write a new implementation for the spec for system dependent stuff and that's it. No more hunting #ifdefs in dozens of files and breaking other code in the process... Regards, Geert ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-11 0:00 ` Geert Bosch @ 1998-04-12 0:00 ` Haug Buerger 1998-04-13 0:00 ` Aaro Koskinen 0 siblings, 1 reply; 16+ messages in thread From: Haug Buerger @ 1998-04-12 0:00 UTC (permalink / raw) Geert Bosch <geert@gonzo.sun3.iaf.nl> wrote: ... >Very easy: put system dependent stuff in a package with a well defined >interface (spec) and use different bodies for different systems. >You'd like to make this system dependent part as small as possible, >but this is a good design principle anyway. Can i use gnatmake with this approach? If yes how? Haug -- For email use haug@zesi.ruhr.de ! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ifdef replacement for GNAT 1998-04-12 0:00 ` Haug Buerger @ 1998-04-13 0:00 ` Aaro Koskinen 0 siblings, 0 replies; 16+ messages in thread From: Aaro Koskinen @ 1998-04-13 0:00 UTC (permalink / raw) haug@localhost.ruhr.de (Haug Buerger) writes: > Geert Bosch <geert@gonzo.sun3.iaf.nl> wrote: > >Very easy: put system dependent stuff in a package with a well defined > >interface (spec) and use different bodies for different systems. > >You'd like to make this system dependent part as small as possible, > >but this is a good design principle anyway. > > Can i use gnatmake with this approach? If yes how? Yes, for each target create a directory which contains the target dependent bodies. When compiling, call gnatmake with parameter -Idir, where the dir is the directory of the target to which you are compiling. -- Aaro Koskinen, aaro@iki.fi, http://www.iki.fi/aaro ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1998-04-15 0:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <352287EE.1CFB@tolstoy.mdc.com> 1998-04-08 0:00 ` ifdef replacement for GNAT John T Vegezzi 312C M 237110 1998-04-09 0:00 ` Robert Dewar 1998-04-10 0:00 ` Dirk Zoller 1998-04-10 0:00 ` Robert Dewar 1998-04-11 0:00 ` nabbasi 1998-04-11 0:00 ` Larry Kilgallen 1998-04-13 0:00 ` Richard Kenner 1998-04-11 0:00 ` Larry Kilgallen 1998-04-11 0:00 ` raw 1998-04-13 0:00 ` Michael F Brenner 1998-04-13 0:00 ` Larry Kilgallen 1998-04-15 0:00 ` Ada Programming Environment [was ifdef replacement for GNAT] Nick Roberts 1998-04-14 0:00 ` ifdef replacement for GNAT Jean-Pierre Rosen 1998-04-11 0:00 ` Geert Bosch 1998-04-12 0:00 ` Haug Buerger 1998-04-13 0:00 ` Aaro Koskinen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox