Re: About pkg() function and compiling options in mkoctfile

On 5/16/20 9:29 PM, José Luis García Pallero wrote:
> Hello:
> 
> Some days ago I asked about the reason of the -fopenmp is present by
> default in mkoctfile
> (https://lists.gnu.org/archive/html/octave-maintainers/2020-05/msg00057.html)
> 
> The reason of my question was that new versions of GCC handle better
> than previous ones with some OpenMP directives. For example, now is
> mandatory to declare explicitly all shared variables in the shared()
> directive when the default(none) option is employed. Prior visions of
> GCC does not require this for variables declared as const, but in the
> standard was always mandatory (see
> http://forum.openmp.org/forum/viewtopic.php?f=3&t=2104). So some code
> must be changed in order to complain with the standard as newer GCC
> versions complain. For example, the GCC provided with Debian stable
> produces error when const variables are declared in shared() (see
> https://sourceforge.net/p/octave/package-releases/417/#681d)
> 
> Then, the fact that mkoctfile activates by default the OpenMP support
> makes some cone not compilable in some systems. I can see that the
> -pthread -fopenmp options for mkoctfile are stored in the globals
> ALL_CFLAGS and ALL_CXXFLAGS, which also contain some information about
> include folders
> 
> But I think that ask the user to edit manually this variables in order
> to install a package is not a good idea. So I propose to add an option
> to the pkg() function in order to activate or deactivate the OpenMP
> (and pthreads maybe) option. Or maybe more in general an option to
> pass information and options from pkg() to mkoctfile. Or both things.
> 
> I think that other discussion could be if mkocfile should activate by
> default the OpenMP dupport
> 
> Thanks
> 


Thank you for providing more information.  You said: "So some code must
be changed".  I still do not understand which code is affected?  Does
this code contain "#pragma omp" sections that are beyond your control?

In general it sounds like a great idea to change code to follow a
standard, rather than relying on implementation defined behavior.  I do
not see a reason to make Octave more complicated, rather than fixing
code to conform to a standard upstream.

Kai