#342 Add a compiler configuration/command line options file

[Simon Sobisch]

Ron implemented the runtime confguration file for GnuCOBOL 2.x in 2015, tracked with [feature-requests:#58].

This issue was brought up by James K. Lowden, which is therefore the owner of this ticket and will be the one that does most of the implementation, which will be done in branches/compiler-configuration.
We currently assume it to even be ready to be integrated into the next GnuCOBOL 3.0 release candidate.

It will also be used for the implementation of [feature-requests:#341].

The changes will also "fix" my initial request to name runtime.conf as runtime.cfg and [bugs:#529] which is about changing the installation path for the configuration files (compiler dialect configuration, runtime configuration and new: compiler configuration) to @datadir@ (/usr/local/share/gnucobol/) instead.

There will be a documentation upload for the new compiler configuration attached to this ticket soon.
In short: it allows to set different values with a current built-in default to a per-site/project/user default (for example to set -std=mf-strict -Wall as new default).

[James K. Lowden]

For details of how the user will use the new configuration file, please see the proposed man page. (In case you haven't used it that way, you can read the file comfortably in Linux with man doc/man/cobc.conf.5.

I suggest runtime.cfg be renamed libcob.conf because "runtime" is vague and ".conf" is the traditional extension for configuration files. That would give us cobc.conf for the compiler and libcob.conf for the library.

Status on configuration:

• all configuration support files are in the cobc directory
• opt_scan and opt_parse are the lex & yacc components
• options.[ch] define the data structures and a few convenient functions for the option-processing logic to call, to access configured options.
• opt_test is a little test program to invoke the configuration "api" and print what it finds.
• the supported options as described in the man page (and supporting grammar) is out of sync with the 3.0 release. That's OK. Once the structure is in place, it's very simple to expand it to support new options.

Once we have consensus on how to proceed, we'll integrate the configuration support into command-line option processing.

Phase 2 is to integrate preprocessor support into cobc, as described in the man page. For me, that's the real objective. Option processing is just a stepping stone to enable the user to configure preprocessors.

Please review the man page and let me know your thoughts.

[Edward Hart]

I can't work out what exactly the changes are.

• Is this an alternative/improvement/replacement for command-line options?
• Is this an alternative/improvement/replacement for the compiler configuration files?
• How do you use it?
• Will this break any existing code?

[Simon Sobisch]

I can't work out what exactly the changes are.

If you can't do this the docs surely need improvement.

Is this an alternative/improvement/replacement for command-line options?

It is an alternative. The reasoning behind this is to create on-site- [or even per-project]-defaults (for example some people would like to default to have runtime checks -debug and compilert optimization -O2 enabled, but you may also specify a default warning set, include directories, ...).

Is this an alternative/improvement/replacement for the compiler configuration files?

It actually is about a not-yet-available compiler configuration file. We currently only have dialect configuration files (compiler wise).

How do you use it?

If the docs don't make this clear now (you did read the manpage, didn't you?) then they must be expanded.

Will this break any existing code?

Not by design. If any bugs get in it will break the compiler (as any change does), especially the command line handling, but we have tests already that make me comfortable.
[Nearly] all "compiler defaults" that are specified in the configuration defaults may be specified [also conflicting] on command line which will always win.

Changing the default name from runtime.cfg to runtime.conf or libcob.conf will change the update handling (installing a new version would replace runtime.cfg in any case so a previously created file need a backup/restore/merge in any case).

[Ron Norman]

My vote is to leave it the way it is as people may already be using this.
The steps to locate runtime.cfg are:
1) If env var COB_RUNTIME_CONFIG is present that defines the exact path/filename to use
2) If env var COB_CONFIG_DIR is present that defines the directory to look for runtime.cfg
3) Look in /install-pat/gnu-cobol/config for runtime.cfg

So the last step (which is the final default) is to look into a directory called .../gnu-cobol/config/ so that is pretty clear it is a place for GnuCOBOL config files.

[Brian Tiffin]

I vote the runtime control features stay in runtime.cfg. And we'll try and make sure people have enough docs on how to wield the power effectively.

For compile time, which I do believe is the focus of this work (really looking forward to single command preprocessor control) then we should create a new batch of config/.conf files. Or one or two new config/preprocessors.conf and include: preprocessors in the configurations that want preprocessors.

[Simon Sobisch]

@jkl: any update on this?

[Simon Sobisch]

I know I was quite happy to see that in the first place, but that has changed.

The main question here is: Why should we add this code into GnuCOBOL - and therefore need to test, adjust, document it - when an existing and portable way to handle this exists: Makefiles (which can additionally but not necessary also track dependencies)?

For the people that don't want to use that, especially on systems where users aren't aware of this, it is even possible to write something similar (including filename/extension based rules) with batch files, /(power)shell / (python)scripts?

For a user-based discussion see [0c375a0456].

[James K. Lowden]

Let's abaondon this idea and close this issue.

The notion as I recall was to help teams/projects to collect compiler options together by providing an explicit mechanism, namely a configuration file. It would control the default behavior of cobc. The way I remember the discussion, I agreed to provide the mechanism as a generalization of a much more specific idea: a way to configure which preprocessors are invoked, and in which order.

On the evidence, both ideas died on the vine. I wrote a configuration-processing library that populated a structure of option settings. That was 3 years ago. It was never incorporated into the release (or trunk). And no one is working on new preprocessors. No need for preprocessor configuration has emerged.

Given a free hand and free time, I would redesign the entire options system, which is far too complex. I would collect all defaults into a single file that the user could patch prior to buildling cobc, and those defaults would percolate into the documentation and online help. But I see neither hand nor time being very free anytime soon.

[Ron Norman]

I agree that reading compile time options from a special control file is NOT a good idea.
I have been doing something similar using 'make' which is the correct place for this.
I have many common 'Makefile' which will include platform specific files that then set variables with the correct compile options that are needed for that platform.
This has been working well for a few decades...

[Simon Sobisch]

Agreed to close because of this reasons.

The idea of a single file likely would need some tweaks in most places, it would be "interesting" to see how this works along with -std to override at compile time (likely also changing default.conf to gc.conf).

Note: adjusting default.conf after running the tests / after install is the current "default" way of a single compiler configuration - but misses all the non-dialect options.

[Simon Sobisch]

Let's revamp this issue with a more "standard" approach

--> we should implement cobc @/path/to/some/file with the file having command line options - same as gcc.

[Eugenio Di Lorenzo]

I made this observation some time ago, and I'll repeat it.

In some cases, a certain source program MUST be compiled with certain options, otherwise it won't work correctly.
Example: -fno-trunc; -fsingle-quote; -fcomplex-odo

In a mainframe environment, using the IBM compiler, you can insert compiler options directly into the source code at the top of every line.
You add a line starting with CBL, followed by all the options the program needs.
This way, anyone who uses that source code will know how it should be compiled by looking at the first line starting with CBL.

It would be like inserting the cobc compiler options at the top of the COBOL source code.
This way, these options are "documented" within the source code and can't be forgotten.
This is even more convenient than having them in a separated configuration file.

[Simon Sobisch]

We do support the IBM and MF directives already, so you may be able to enforce special options that way. For missing ones (where we can point to IBM/MF docs) those can be added, if missing.
But for a common set of arguments (or a very long input list in DOS or other small environments where you cannot pass that much arguments on the command line) the @file syntax (that then includes for example listing options or fine-tuned compiler options for every source) helps a lot and brings us nearer to "common gcc behaviour", which is itself a bonus already.