From jamie@zfatal.cern.ch Wed Apr 1 11:50:56 1995 Received: from dxmint.cern.ch by dkuug.dk with SMTP id AA18139 (5.65c8/IDA-1.4.4j for ); Wed, 29 Mar 1995 09:51:02 +0200 Received: from zfatal.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02244; Wed, 29 Mar 1995 09:50:59 +0200 Received: by zfatal.cern.ch (AIX 3.2/UCB 5.64/4.03) id AA36985; Wed, 29 Mar 1995 09:50:57 +0200 From: jamie@zfatal.cern.ch (Jamie Shiers) Message-Id: <9503290750.AA36985@zfatal.cern.ch> Subject: Conditional Compilation To: SC22WG5@dkuug.dk Date: Wed, 29 Mar 1995 09:50:56 +0200 (METDST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2406 X-Charset: ASCII X-Char-Esc: 29 I have so far avoided joining the conditional compilation fray, but all good things must come to an end... I would like to explain what we do regarding conditional compilation at CERN, and our plans for the future. A number of packages that provide support for conditional compilation have been written over the years in High Energy Physics - typically these have also performed other tasks as well. At CERN, we have over 2 M lines of code containing home-brew conditional compilation and include-like statements in the CERN Program Library. There are also many hundreds of thousands of lines of experiment specific code that are similarly marked up. For a number of reasons, we want to move away from roll-your-own solutions and migrate to industry "standards". In the case of conditional compilation (and include processing), this means using the C preprocessor. On many Unix platforms, including all of those which we directly support at CERN, the vendor supplied Fortran compiler will automatically invoke the C preprocessor for files ending in .F (as opposed to .f) On other platforms, we invoke the C preprocessor explicitly. Of course, one can argue that the C preprocessor doesn't do x, y or z, or is generally not nice, but it has been demonstrated that it can solve our requirements and, we believe, those of the High Energy Physics (HEP) community in general. Our own preprocessors have included support for constructs of mind-boggling complexity, that sometimes even the authors of the preprocessors find difficulty in understanding. However, we have found the C preprocessor to be an entirely adequate replacement. Another reason for adopting and existing, adequate, solution is that of mixed-language programming. If Fortran is to survive as a programming language in HEP, it will be as 'yet-another-language', and not as 'the' language. People programming in these other languages typically expect support for the C preprocessor (which gives a mild hint as to what they might be). Having to use two different preprocessors is at least in the "not nice" category. Therefore, speaking at least for the CERN Program Library, we would support adopting the C preprocessor for Fortran. We would not support any other initiative. -- Jamie Shiers, CERN Program Librarian, Application Software and Databases Group, Computing and Networks Division CERN 1211 Geneva 23 Switzerland