Re: Questions about configure/building regarding Qt and Lua

[Daniel J S. <dan...@ie...>]

I'm attaching a patch file with some mods that work for me.  Should I 
open a bug report and post the diff file there?  That will allow more 
organized development.

More comments below...

On 08/31/2017 07:36 PM, sfeam wrote:
> On Thursday, 31 August 2017 16:05:48 Daniel J Sebald wrote:
>> I upgraded to Mint 18.2 here, and I'm going through all the usually
>> system rebuilding...
>>
>> Why does configure report:
>>
>> checking for QT... yes
>> configure: WARNING: The Qt terminal will use Qt5.
>>
>> Is it simply because Qt5 is considered experimental support at this stage?
> 
> Just because the macro autotools provides to write something non-fatal
> during configuration is AC_MSG_WARN.  You'd think they would provide
> something blander like AC_MSG_JUST_IN_CASE_YOU_CARE, but no.
> WARN is better than the alternatives ERROR or FAILURE.

There is AC_MSG_RESULT, which is used a few other places in the 
configure.ac file.  If you want to add "checking " to the front to match 
all the other lines that's fine.


>> Also, when compiling I ran into a missing lrelease utility for Qt:
>>
>> /bin/bash: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: No such file or
>> directory
>> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
>> make[4]: *** [qtgnuplot_fr.qm] Error 127
>>
>> Should configure check for that lrelease file that is being included?
> 
> Sure.  But I don't know how to do that.  lrelease is not a library, so the
> library test macros don't help.

Asking for the version:

sebald@ ~ $ lrelease -version
lrelease version 5.5.1

should return with 0 if lrelease is present, otherwise return non-zero. 
It should be possible to run the command from configure and check the 
result.


>> It isn't too much trouble to find the package and install lrelease
>> (qttools5-dev-tools), but that package isn't automatically installed
>> with all the other Qt5 packages as a requirement.
> 
> That seems more like a failure of the mint package dependencies than
> something gnuplot's configure script is responsible for.
> FWIW on my machines lrelease does not come in a separate *-dev-*
> package.  It's in qttools5 proper.

Yes, it does seem that way.  Maybe the developers will catch this 
eventually.


>> After installing
>> qttools5-dev-tools, compilation continues with 29 translations for Qt.
>>
>> I then ran into this problem:
>>
>> make[2]: Entering directory '/usr/local/src/gnuplot/gnuplot/build1/docs'
>> lua5.2 /home/sebald/gnuplot/gnuplot/gnuplot/term/lua/gnuplot-tikz.lua
>> termhelp > gnuplot-tikz.help
>> /bin/bash: lua5.2: command not found
>> Makefile:979: recipe for target 'gnuplot-tikz.help' failed
>> make[2]: *** [gnuplot-tikz.help] Error 127
>>
>> which is of the same variety as the previous problem.  I had to install
>> lua5.2 package because it isn't a requirement for liblua5.2-dev package.
>>    Should configure check for the lua executable?
> 
> The configure script uses pkg-config to check for lua.
> It checks for "lua", and if that fails it checks for "lua5.1", "lua5.2", "lua5.3".
> So again it sounds like mint weirdness.  If pkg-config is reporting that you
> have lua installed but really you do not, I would consider that a system
> configuration error.
> 
> But also it's weird that bash is trying to run explicitly lua5.2.
> Normally it just runs "lua" and that invokes the current installed version
> whatever it is.  Can you pin down what script this is, exactly?  I don't
> see any such script in the gnuplot source.

Ah, that's probably because these are two different things.  The 
$PKG_CONFIG is checking for the associated package files in the 
directory where the pertinent library was built.  That package is 
lua5.2.  I assume this package construct is because there is some code 
compiled into gnuplot that interacts with lua libraries.

But what was failing is the executable name, "lua"...which typically 
consists of a link to the (or some) package directory, e.g.,

lrwxrwxrwx 1 root root 33 Aug 31 15:50 /usr/bin/lua -> 
/etc/alternatives/lua-interpreter

well, in this case there is an extra level of abstraction.

I suppose the idea is that the library is used to construct something 
that can input to the external "lua" app.  The configure.ac doesn't make 
any distinction between those.  I've added a LUA_CMD=lua and changed 
$(LUA) to $(LUA_CMD) in a select few locations.

As with lrelease, the LUA_CMD could be verified with

sebald@ ~ $ lua -v
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio

return 0 as opposed to -1.  I'm just assuming it is present for now.

Dan