help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mkoctfile and OpenMP


From: José Luis García Pallero
Subject: Re: mkoctfile and OpenMP
Date: Tue, 17 Apr 2012 15:04:28 +0200

El día 16 de abril de 2012 19:18, Luke M <address@hidden> escribió:
>
> Jordi Gutiérrez Hermoso-2 wrote
>>
>>>
>>> Mmmm..., if -Wall and other warning flags, -I, -L, -l and -D are
>>> recognized by mkocfile, why not -f options and -O options?
>>
>> -Wall is recognised only because of a bug in mkoctfile. It's not
>> really recognised. Look at the help docstring for mkoctfile for -W,
>> and you'll see that it's actually supposed to be for passing options
>> to the compiler, but due to a bug, it passes -Wall instead, and there
>> is no way to pass options to the compiler this way. The other flags
>> are all handled specially, and there's specific code to handle those.
>> We just don't have enough cases to check for all possible flags that
>> you can pass to mkoctfile.
>>
>>>> Right now, you can use the environment variables CFLAGS, CXXFLAGS, and
>>>> LDFLAGS to pass options to the C compiler, C++ compiler, or linker,
>>>> respectively.
>>>
>>> OK, I didn't know that mkoctfile recognizes CFLAGS, CXXFLAGS nor
>>> LDFLAGS. I will use them. Should I suppose that when I use pkg()
>>> function from Octave this CFLAGS, CXXFLAGS and LDFLAGS are recognized
>>> and used too?
>>
>> Yes, I don't know of any other way to pass options that works right
>> now. I don't know how to fix mkoctfile. It would be helpful if we got
>> this fixed once and for all, because everyone seems to think that
>> mkoctfile accepts the same arguments as gcc, and frankly, it probably
>> should.
>>
>> - Jordi G. H.
>>
>
> Looking at the code for mkoctfile, it looks like it just passes anything
> that starts with -W straight through, except for linker options that start
> with "-Wl," which it lumps in with the other linker flags it finds.  The
> example given, "-Wa,OPTION" would pass options to the assembler.
>
> It seems to me (just looking at the code, I don't have my dev machine handy
> at the moment) that there is only a "bug" with the documentation; this is
> just a feature that is not fully implemented.  Well, it might be a bug that
> it passes those options to the linker as well as the compiler, I'm not sure.
> I'm not used to separating those operations like mkoctfile does, so I don't
> know what the linker would do with them.  Other than that it looks (no
> promises!) like it might be somewhat trivial to add pass-through support for
> -f and -O, i.e.:
>
>      else if (starts_with (arg, "-W"))
>        {
>          pass_on_options += (" " + arg);
>        }
>
> becomes
>
>      else if (starts_with (arg, "-W") || starts_with (arg, "-f") ||
> starts_with (arg, "-O"))
>        {
>          pass_on_options += (" " + arg);
>        }
>
> Or, instead of chasing compiler options around trying to support them, it
> could just be made to simply pass through any unrecognized options.  That
> way developers could use more advanced debugging and optimization options,
> or if they wanted to use some fancy new C++11 features in their octfiles,
> they could just pass -std=c++0x straight to mkoctfile.  This could also
> simplify the code a bit by removing things that are just passed through
> anyway, like -D flags.

I agree. I think that any option should be passed to the compiler, so
mkoctfile could be only an intermediate script for passing the
particular Octave paths and libraries

Cheers

>
> --
> View this message in context: 
> http://octave.1599824.n4.nabble.com/mkoctfile-and-OpenMP-tp4561550p4562192.html
> Sent from the Octave - General mailing list archive at Nabble.com.
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://mailman.cae.wisc.edu/listinfo/help-octave



-- 
*****************************************
José Luis García Pallero
address@hidden
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************


reply via email to

[Prev in Thread] Current Thread [Next in Thread]