#413 Modernisation of the compiler

[Vincent (Bryan) Coen]

On the subject of modernising GC I have some strong suggestions some of
which I posted in the features report some years back :

1. Allow programs using screen section to use a standard GUI interface
   that will work with KDE and Gnome (subject to a setting).

overridesoverrides2. Same as 1. but for using a web browser although there might be
issues say when wishing to use Firefox or Chrome etc

More important allow a compile to executable (-x) to generate a
STATIC program with only light usage of steering lines to cobc where
program can be using or not using Storage section and or ISAM files
regardless of variant i.e., BDB, VBISAM etc) although it might mean that
only some can be used if static version of their library are not
available or possible.
This should not need to use the GNU make tool where ever not needed to
stick to the KISS methods.

1. Although the cobc steering commands to use the one's used with
   compilers from IBM and Micro Focus to be used where ever possible and if
   needed to create new ones where the list of such is not currently in
   IBM/MF command sets and shown and listed by command order and by
   function order.

   From 4. Allow when building the compiler to have pre-built commands
   already set up as a site wide set.

   From 5. Allow the same from a config file that overrides / in
   addition to for project specific changes.

   From 6. Allow the same from a Local config file that is present in
   the source directory to override setting from 5., and 6.

   From 7. Allow the same from within say a $SET on line 1 of a source
   file for program specific changes, if any.

5 - 8 will allow usage of abbreviated compiler steering using the IBM /
MF abbreviated format commands

Will that be enough for getting on with ?

[Simon Sobisch]

Thanks for taking the time to recap those suggestions on a single place.

1 and 2 - totally and patches welcome.
I'm available to help people writing other "screenio" frontends, but won't do it myself.

3 static: as you've already said: a real static option is only possible if you have all libraries available as static ones, too, which isn't normally the case.
What is the issue with keeping N libraries around that are already there? I guess the "just one executable and it works everywhere" is the goal - but even then you commonly will have glibc symbols and other stuff which gets in the way with a "classic" static link.
Static linking of the COBOL parts is already possible and works well: cobc -x main.cob *.cob. Note: GC4+ splits libcob itself, you will commonly have 1 libcob, one other for each of the ISAM interfaces you may want to use - you can have multiple ones on the same time with runtime-configuration and default; and hopefully also 1 for xml, 1-2 for json and 1-2 for screenio - all delay-loaded so "if not used - not loaded at all - no dependency to it".

The "system wide default" config seems to be tracked at [feature-requests:#160] already and is related to the suggested "check for config file in source directory".
But as those are actually "external" things someone could come up with a configured-cobc script that does all of that - default, then inspect for the config file from the source file upwards gathering the commands, then executing cobc finally. I think that would be a better approach than to wire all that into cobc. Do you agree?

7 is already possible for many options and always overrides everything else. We don't have everything covered yet for $SET yet, the @OPTIONS (Fujitsu) is nearly not done and the GC specific one could be extended, too. (I personally think that this part needs a rewrite)
More options are commonly worked on depending on the need (or related changes).

I guess 3 is about cobc --help?

I have no clue what you mean with 5-8.