Sun 14 Aug 2016 03:57:17 PM UTC, comment #10:
carandraug said:
> [...] therefore "-p" would be the flags that mkoctfile uses. [...] in my view that includes the flags required by Octave plus whatever the user has set in the environment if any.
I thought about this again last night and I'm not so sure if that's the most obvious behaviour after all.
Mike Miller said:
> Agree with jwe, I think it's important that mkoctfile treats CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, etc as user variables that can be overridden from the environment, and default to empty (in the case of LDFLAGS) or to a trivial default (in the case of CXXFLAGS="-g -O2").
>
> But do we want to append the built-in defaults to the user values and allow the full set of flags to be exported? Or would that be too confusing?
Yes, mkoctfile should account for XFLAGS set in the environment but it doesn't have to echo them back when using "mkoctfile -p".
If mkoctfile is called to make an oct file, then it should use env variables. If it is called with "-p", then the user will be handling those flags and it is up to him to append any environment variables that it sees fit, and it will be up to him to ignore the environment variables as well. pkg-config also does this, it returns only the flags required and ignores environment variables.
But then the purpose of "mkoctfile -p" overlaps with the purpose of "octave-config" and the newly reported bug about supporting pkg-config. So why do we even need "mkoctfile -p"?
|
Sun 14 Aug 2016 02:01:06 PM UTC, comment #9:
I don't see the reason to delay. I find it awfully confusing that mkoctfile -p doesn't return the actual set of values that it uses internally to compile objects.
|
Sat 13 Aug 2016 11:41:46 PM UTC, comment #8:
jwe said on comment #7:
> That we provide octave-config and not a pkg-config file is really just historical (pkg-config wasn't around yet?). Switching to pkg-config and deprecating octave-config is probably worthy of a separate bug report/feature request.
New bug report opened as bug #48775
Should then fixing this be delayed until we provide a pkg-config file then?
|
Sat 13 Aug 2016 11:20:03 PM UTC, comment #7:
That we provide octave-config and not a pkg-config file is really just historical (pkg-config wasn't around yet?). Switching to pkg-config and deprecating octave-config is probably worthy of a separate bug report/feature request.
|
Sat 13 Aug 2016 11:09:05 PM UTC, comment #6:
That explains the large set of flags. I never quite understood why we had so many and why they looked kind of redundant.
I thought the purpose of mkoctfile was to build oct files and that therefore "-p" would be the flags that mkoctfile uses. Because mkoctfile should not ignore user environment variables, in my view that includes the flags required by Octave plus whatever the user has set in the environment if any.
If a user would want to get only the flags that Octave requires (instead of the flags that mkoctfile will use), then it should use octave-config (which I now realize doesn't really have any flags and is not an Octave specific version of pkg-config).
|
Sat 13 Aug 2016 10:44:32 PM UTC, comment #5:
Agree with jwe, I think it's important that mkoctfile treats CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, etc as user variables that can be overridden from the environment, and default to empty (in the case of LDFLAGS) or to a trivial default (in the case of CXXFLAGS="-g -O2").
But do we want to append the built-in defaults to the user values and allow the full set of flags to be exported? Or would that be too confusing?
For example could we combine the user's CPPFLAGS with what is currently called INCFLAGS, and export that from "mkoctfile -p CPPFLAGS"? Same with user's CXXFLAGS and XTRA_CXXFLAGS for "mkoctfile -p CXXFLAGS"?
Another enhancement might be to work on the naming convention of the built-in compiler/linker options. It usually takes me a few tries of guessing to figure out which of LFLAGS, OCTAVE_LIBS, DL_LDFLAGS, I need to export to build something.
It might be a nice enhancement to work on the naming scheme for exporting the default flags from mkoctfile.
|
Sat 13 Aug 2016 10:27:10 PM UTC, comment #4:
The LDFLAGS variable is normally empty and allows the user to add options by setting LDFLAGS in the environment.
It looks like the LFLAGS variable is just there to ensure that -L$(octlibdir) is included in the linker options when it is not a directory that is normally searched by the linker. I suppose it is similar to AM_LDFLAGS in automake. LFLAGS may not be the best name, but this job needs to be done in some way. It's probably best to keep it separate from LDFLAGS so that if someone sets LDFLAGS in the environment, they don't have to also include -L/usr/local/octave/lib/.../whatever. Users should be able to set LDFLAGS independently and still expect things to work.
|
Sat 13 Aug 2016 02:52:15 PM UTC, comment #3:
Adding jwe to the CC list. I think this is still some sort of simple misunderstanding.
|
Sat 13 Aug 2016 02:46:15 PM UTC, comment #2:
Looking into mkoctfile.in.cc, I see that LFLAGS is supposedly being set as something from configure.ac
While LFLAGS is being set "manually"
I don't quite get it, there's no tests units for this, and I'm not comfortable tweaking there. Could anyone more familiar have its hand at it?
|
Fri 12 Aug 2016 12:24:50 AM UTC, comment #1:
This is us just being stupid. If you try 'mkoctfile -h' the documentation clearly says that LDFLAGS should be a configuration variable.
I would say go ahead and make the change. We can keep LFLAGS for another two releases.
|
Tue 02 Aug 2016 01:15:32 AM UTC, original submission:
From the Make manual https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
However, mkoctfile includes the LDFLAGS into LFLAGS instead
This is bug is also present in Octave 4.0.1 (and possibly in previous versions)
and so there's backwards compatibility implications about fixing this. But since mkoctifle does not handle lex, it would be possible to keep using LDFLAGS incorrectly for a few versions, before removing LFLAGS completely.
|