Tue 24 Jan 2017 11:35:36 PM UTC, comment #12:
On my system, qt5 is the default and I don't use any qt version options. Without the patch, I see the -qt5 option when running configure the first time (with the cache) but not when running it again.
I'll push the change. If it breaks something else let me know.
|
Tue 24 Jan 2017 11:31:27 PM UTC, comment #11:
Sorry to be late to the party. jwe's patch also works for me I think it should be applied.
|
Tue 24 Jan 2017 11:15:50 PM UTC, comment #10:
jwe's patch works for me, the FLAGS all have the right -qt4 option after re-running config.status and the build is a success, so I assume the same would work in the other direction (when Qt 4 is the default but -qt5 is used).
|
Tue 24 Jan 2017 10:53:15 PM UTC, comment #9:
Thanks, I can reproduce this now. I think I had been running config.status --recheck, but not actually using it to regenerate the Makefile, or something. Now I can see that the values for moc, etc, are loaded from the cache and no FLAGS are appended.
I'll try with your patch now that I can actually get the error to happen.
|
Tue 24 Jan 2017 10:40:43 PM UTC, comment #8:
Mike, are you using "configure -C" to enable config.cache? I do see the problem if I use the cache:
note that
It's the "--recheck" part (with the cache) that causes the trouble. This happens because of the problem that I noted in comment #6 about using MOC as the cache variable.
|
Tue 24 Jan 2017 10:05:03 PM UTC, comment #7:
Hmm, I can't reproduce this either, working on a system where Qt 5 is the default but I am building with --with-qt=4. I either have to set PATH explicitly to use the /usr/lib/x86_64-linux-gnu/qt4/bin directory, or configure finds the moc-qt4 symlinks first, or it finds the qtchooser executable and does the right thing in the end anyway. If qtchooser is found, even if MOC and the rest of them are cached, configure still automatically appends the -qt4 option to all commands. If qtchooser is not installed, then how could this work? I am not seeing the case where it fails to append the necessary -qt4 or -qt5 option.
|
Tue 24 Jan 2017 07:57:36 PM UTC, comment #6:
Could you try the attached change instead? I think the caching is screwed up because we use the variable MOC when checking for moc-qt$ver. Since AC_CHECK_TOOL uses the cache, it finds the value for MOC from the cache and then skipping the check for qtchooser.
It may be that my solution can fail in some other ways, but it seems to work for me to get MOCFLAGS set again when running config.status --recheck
If this solution fails for you, then I guess I'd still like to understand why and see if I can duplicate the problem.
(file #39552)
|
Tue 24 Jan 2017 01:34:32 AM UTC, comment #5:
The attached patch works for me. I don't know if it is the best, but it might be good enough.
(file #39545)
|
Tue 24 Jan 2017 01:10:20 AM UTC, comment #4:
Yes, I want to save the value for MOC and MOCFLAGS together. I tried changing the line
to
However, the problem still remains. According to the documentation for AC_ARG_VAR
This is indeed what seems to be happening. The initial value is "", and then it is calculated by this stanza in m4/acinclude.m4.
The cached value is always "", rather than the calculated value, which doesn't wark. I'm trying something with AC_CACHE_CHECK right now to see if that works.
|
Mon 23 Jan 2017 11:52:53 PM UTC, comment #3:
Ok, I think you are saying that if the MOC variable is cached, then the MOCFLAGS variable must also be cached, and I agree that is probably what is going on here.
Compilers and compiler flags are typically saved with AC_ARG_VAR, for example CC and CFLAGS, CXX and CXXFLAGS, so they are either remembered or not together, while we have LRELEASE, MOC, RCC, and UIC saved as cached variables explicitly, but not the corresponding FLAGS variables. Yes we should either save or not save both sets of variables in the same way.
|
Mon 23 Jan 2017 11:45:34 PM UTC, comment #2:
I don't think caching the variables will help in this case, since saving the cache to a file is always optional, but declaring them as AC_ARG_VAR would force them to be saved in the command line arguments passed to configure when it is re-run. It's probably the caching of something else that is causing the appropriate test to be bypassed so that the right options are not calculated. I would take a look at what commands are used to determine whether the -qt4 or -qt5 options are needed, and whether they are bypassed in some cases while the options themselves are not saved.
This isn't a problem on my system because Qt 5 is the default, but maybe forcing a Qt 4 build would trigger this for me.
|
Mon 23 Jan 2017 11:24:44 PM UTC, comment #1:
Further information. This is the series of commands that get run when the Autotools system discovers that the build system itself is out of date.
And the problem that results is that the resulting Makefile does not have the varibale MOCFLAGS set to "-qt5". It is empty, along with UICFLAGS and RCCFLAGS.
Maybe Octave needs to cache these configure variables?
|
Mon 23 Jan 2017 11:14:34 PM UTC, original submission:
This is a complicated issue, which I can work around, but it does indicate a problem with the build system on the development branch.
Recently there was a series of whitespace changes to the entire codebase to eliminate trailing newlines at the end of files. After hg update, I ran make which proceeded to re-run configure and then do the build. However, the build failed as shown below.
I have two versions of Qt development libraries installed on the computer, Qt4 and Qt5. If I don't specify a version to Octave's configure script then it defaults to Qt5. That's fine, and if I look at the synopsys at the end of configure I see:
As one can see, it has chose qt5 correctly, and is adding the -qt5 option to the 'moc' command.
However, when the build system automatically re-runs configure, I am getting a different result.
As you can see, it is no longer using the -qt5 option. Thus, when it runs I pick up the version for Qt4.8.6 and I get the error.
This may be because of caching. This is the result during the re-run of configure.
And this is the result of a configure run after 'make distclean'
There are more things that get tested, including qtchooser.
|