Reviewing the default compiler options defined in cmake/DefaultFlags.cmake

[vmagnin]

The default compiler options for DEBUG and RELEASE modes are defined in cmake/DefaultFlags.cmake. The main compiler used for the development of gtk-fortran is GFortran. The second one is Intel ifx which allows to obtain other warnings.

• What improvements can be made in this cmake/DefaultFlags.cmake file?
• At the moment, the Fortran 2008 standard is imposed in the DEBUG mode with GFortran (-std=f2008). Should it be completely removed, or put in RELEASE mode, should it be set also for ifx?
• The -pedantic option is used in the DEBUG mode with GFortran, to exclude Fortran extensions. If -std=f2008 is removed, will -pedantic still have an effect?

[vmagnin]

Useful links concerning GFortran:

• https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html
• https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
• https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
• https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

[vmagnin]

Concerning ifx debug mode, we should probably add the option -O0 to avoid this repeated warning:

remark #10440: Note that use of a debug option without any optimization-level option will turnoff most compiler optimizations similar to use of '-O0'

[florianober]

I think for the standard there are three possible ways:

• not to fix the standard at all
• fix it only for the RELEASE mode (good choice to ensure compilation)
• fix it for both DEBUG and RELEASE mode (consistent choice if you want to stick to one specific standard)

the -pedantic switch is good to reject for example GNU extensions.

[vmagnin]

One reason to use -std=f2008 was to avoid using too recent things and stay compatible with relatively old compilers while developing gtk-fortran.

But I have just discovered that CMake offers more than DEBUG and RELEASE build types:
https://cmake.org/cmake/help/v3.31/variable/CMAKE_BUILD_TYPE.html

You can even define your own custom types. We could therefore define DEBUG and RELEASE flags for the users, and I could define also my own DEV flags when developing the library:

  set(
    CMAKE_Fortran_FLAGS_DEV_INIT
    ...
  )

which could be chosen with the CMake option -D CMAKE_BUILD_TYPE=dev

[florianober]

yes, you could do something like this, but why?
Who should use the debug build mode other than you and maybe a few other enthusiasts?
Thus, if your argument is: "Avoid too recent things...", then it would be best to add the flag to the release build mode too. Maybe you can use f2018, but this is up to you.

But at the moment it is only in your debug mode, and the user could get stuck while on your side everything seems to be alright ;)

[vmagnin]

Thanks for feedback @florianober
I have removed the -std=f2008 GFortran flag (I am working in my branch https://github.com/vmagnin/gtk-fortran/tree/gtk4-vmagnin). If I need, I can anyway override the CMake DEBUG flags with something like cmake -D CMAKE_Fortran_FLAGS_DEBUG="-g -std=f2018" ..

[vmagnin]

I am also working on Flang flags. For the moment a few errors occur during the build, but they can be ignored with make -i. Flang provides its own errors and warnings and will help made the code even more standard compliant.

Flang has -mtune and -march options, but does not seem to have a native value for automatic choice (at the moment ?), contrarily to GFortran. I therefore do not put them in the RELEASE flags.
https://flang.llvm.org/docs/FlangCommandLineReference.html

$ flang --version
flang version 20.1.3 (Fedora 20.1.3-1.fc42)

[vmagnin]

Do you have a suggestion for simple plots (lines, histograms etc. nothing fancy).

A solution is to write a Gnuplot file then call Gnuplot with a call execute_command_line instruction.

You can also have a look at https://github.com/vmagnin/gtk-fortran/wiki/Alternatives-to-gtk-fortran
In the list, there is https://github.com/kookma/ogpf ("ogpf is Object based interface to GnuPlot from Fortran 2003, 2008 and later ")

[florianober]

Yes, this would be possible. Furthermore, one could write a datafile and use python and matplotlib for plotting.
I'm not quite sure if one of these solutions is better than using plplot with its fortran bindings.
Thanks

[jtappin]

The main reasons for going with plplot for the main route to graphics output were:

1. It had a native Fortran interface.
2. It could use an externally-defined window as its output.
3. It was (unlike most other fortran-callable plot libraries) actively maintained.

Unfortunately the last of these appears to no longer be the case, the GDL team were forced in the end to fork the relevant bits into the GDL codebase.

There is supposed to be a way to use GNUplot as a library, but documentation appears to be entirely absent.

I don't have much time for software development at the moment so I can't offer to help in the short term (what little time I do have is mostly spent with GDL). I am considering going part time when some of the projects I am working on at present start to wind down, so maybe in a year or so I'll be able to get back to GTK Fortran.

[vmagnin]

Unfortunately the last of these appears to no longer be the case, the GDL team were forced in the end to fork the relevant bits into the GDL codebase.

There was a post about reviving a little PLplot in December:
https://fortran-lang.discourse.group/t/cygwin-and-cmake-make-problems-slightly-off-topic-but-not-entirely/9016

[p-pap]

Yes, this would be possible. Furthermore, one could write a datafile and use python and matplotlib for plotting. I'm not quite sure if one of these solutions is better than using plplot with its fortran bindings. Thanks

I am quite sure using plplot still is a better solution than any other options I can think of, and I don't see this changing in the foreseeable future. I maintain gtk-fortran packages for Slackware and Slackware-Current, where GFortran is used to build the package and plplot support is included. plplot itself is also included as a recommended package.

[vmagnin]

Concerning GFortran, I have removed:

• -pedantic whose behavior is not clear and which is probably useless without -std
• -Wtabs already included into -Wall
• -pthread already included in the flags defined for GTK (now displayed when calling CMake)