[Fortran] preprocessor of NAG compiler has limits

[foxtran]

Some Fortran codebases actively uses #include preprocessor statements. Usually, it compiles nicely, however, preprocessor of NAG compiler has the following limits:

Item	Limits
Maximum INCLUDE file nesting	20
Maximum number of INCLUDE file references per compilation	2047

Then, one needs to adjust codebase to avoid this limitations.

It would be nice to check number of #include preprocessor statements and give warnings if their number exceeds NAG limits.

NAG compiler limits: https://support.nag.com/nagware/np/r72_doc/manual/compiler_2_7.html#LIMITS

[alvrogd]

Hi @foxtran,

Thanks for your suggestion to improve the Open Catalog!

That's an interesting tip we weren't aware of. As far as I can recall, all existing recommendations focus on language use, while documenting a "compiler technical limitation" would be a first for the catalog. Nevertheless, this would be useful, for example, for preventing later portability issues.

One option would be adding a new general recommendation for "compiler limitations", under which we can start documenting specific scenarios such as yours. I assume this new recommendation would require some discussion, but it could be similar to PWR075: general intro on how compiler-specific limitations should be respected to maximize portability + document concrete scenarios (https://github.com/codee-com/open-catalog/issues/89).

For now, I'll leave this issue open so we don't lose track of it. Naturally, if you'd like to make a proposal, feel free to submit a PR! You can use existing recommendations as a reference (e.g., PWR075), and I've also included a few tips at the bottom of this message.

Steps for adding a new recommendation (click me)

1. Each recommendation resides in its own directory under Checks/. Create the directory and update the list of checks in the README.md at the root of the repository.

2. Add a README.md file that includes the following:

   • Title: ID (e.g., the next available PWR number) + Name of the recommendation.
   • Issue: A brief description (1-2 sentences) of how the discouraged practice impacts the code.
   • Actions: A brief explanation (1-2 sentences) of how to refactor the code from the discouraged to the encouraged practice.
   • Relevance: A more detailed explanation of why adopting the recommended practice is beneficial, expanding on the previous points.
   • Code examples: Include a before-and-after code example to illustrate the improvement.
   • References: Add links or references for further reading, if available.

3. Create standalone example and solution source files containing the code examples.

4. Optionally, include a benchmark demonstrating the before-and-after performance impact of the change. In cases like this, the expectation is that the performance of the code should not degrade.

For reference, feel free to check out previous PRs to see how these steps are implemented in practice. For example, this is the PR that added PWR075.

Naturally, don't hesitate to ask at any moment if you have any issues. We'll be glad to help!